Scrum-Projekte planen mit System

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. die Planung eine zentrale RolleRolleRolle bezeichnet eine temporäre Funktion einer Person oder Organisationseinheit innerhalb der Projektorganisation. Eine Rolle wird beschrieben durch Aufgaben, Befugnisse und Verantwortungen. Zur vollständigen Definition einer Rolle gehört die Angabe, ob sie teilbar (d.h. ob sie von mehreren Personen wahrgenommen werden kann) und kombinierbar (d.h. ob sie mit anderen Rollen gemeinsam von einer einzigen Person wahrgenommen werden kann). ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt. Dominik Maximini stellt im ersten Teil des Beitrags das Vorgehen bei der Planung kurz vor, beleuchtet Besonderheiten und zeigt FehlerFehlerFehler sind unvermeidlich bei Projekten. Andererseits ist das Ziel des Projektmanagements und insbesondere des Qualitätsmanagements, Fehler zu verhindern. Aus Sicht des Qualitätsmanagements stellt ein Fehler eine "Nichtkonformität" dar, die unverzüglich behoben werden muss und deren Ursache abzustellen ist. Aus Sicht des Projektmanagements stellt ein Fehler hingegen eine Möglichkeit dar, neue Erkenntnisse zu gewinnen. auf, die in der Praxis häufig gemacht werden. Der zweite und abschließende Teil beschreibt das Vorgehen ausführlich an einem praxisnahen Beispiel.

DownloadDownload

Artikelserie

  1. Besonderheiten und Voraussetzungen
  2. Vorgehen in der Praxis

Scrum-Projekte planen mit System

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. die Planung eine zentrale RolleRolleRolle bezeichnet eine temporäre Funktion einer Person oder Organisationseinheit innerhalb der Projektorganisation. Eine Rolle wird beschrieben durch Aufgaben, Befugnisse und Verantwortungen. Zur vollständigen Definition einer Rolle gehört die Angabe, ob sie teilbar (d.h. ob sie von mehreren Personen wahrgenommen werden kann) und kombinierbar (d.h. ob sie mit anderen Rollen gemeinsam von einer einzigen Person wahrgenommen werden kann). ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt. Dominik Maximini stellt im ersten Teil des Beitrags das Vorgehen bei der Planung kurz vor, beleuchtet Besonderheiten und zeigt FehlerFehlerFehler sind unvermeidlich bei Projekten. Andererseits ist das Ziel des Projektmanagements und insbesondere des Qualitätsmanagements, Fehler zu verhindern. Aus Sicht des Qualitätsmanagements stellt ein Fehler eine "Nichtkonformität" dar, die unverzüglich behoben werden muss und deren Ursache abzustellen ist. Aus Sicht des Projektmanagements stellt ein Fehler hingegen eine Möglichkeit dar, neue Erkenntnisse zu gewinnen. auf, die in der Praxis häufig gemacht werden. Der zweite und abschließende Teil beschreibt das Vorgehen ausführlich an einem praxisnahen Beispiel.

Scrum wird in immer mehr Software-Projekten jeder Größe eingesetzt. Dabei ist natürlich auch die Planung wesentlich, allerdings verschiebt sich im Vergleich zu traditionellen Ansätzen der ZeitpunktZeitpunktIn der Netzplantechnik wird mit " Zeitpunkt " ein Punkt auf einer frei gewählten Zeitachse bezeichnet, solange diese noch nicht auf die Echtzeit abgebildet ist. dafür – denn anstatt einer langen, vorgelagerten Planungsphase erfolgt in Scrum die Planung hauptsächlich rollierend und parallel zur Entwicklung. Leider messen aber selbst erfahrene Scrum-Anwender der Planung oft zu wenig Bedeutung bei, denn häufig hört man Aussagen wie: "Wir sind agil, wir brauchen keine Planung!", oder: "Das Agile Manifest sagt, dass wir auf Veränderungen reagieren und keinem Plan folgen müssen!"

Beide Aussagen sind falsch und führen im schlimmsten Fall dazu, dass die unzureichend geplanten Projekte am Ende scheitern. Typische Fehler bei der Planung sind, dass z.B. ohne klares ZielZielZiel ist ein prognostizierter Zustand, der ein bestimmtes Handeln legitimiert. Um ein Ziel zu erreichen ist ein Plan erforderlich. Sowohl Ziel als auch Plan sind charakterischte Bestandteile eines Projekts . Siehe Projektziel . gestartet wird oder keinerlei AufwandsschätzungAufwandsschätzungAufwandsschätzung wird in drei Bedeutungen verwendet: Das Erstellen einer Prognose über den Aufwand, der erforderlich ist, um eine Aufgabe durchzuführen oder ein Produkt herzustellen Methode, um Aufwände zu prognostizieren Schätzwert für einen Aufwand erfolgt. Ohne Aufwandsschätzung lässt sich jedoch die Velocity, also die Geschwindigkeit des Teams, nicht ermitteln und man erreicht in der Folge auch keine Prognosesicherheit. Kommt dann die Nachfrage des Geschäftsführers, wie gut sich das Team macht, und ob die angestrebte Produktivitätssteigerung erreicht wurde, ist wieder Unschuldslächeln und Achselzucken angesagt, da man ja keine Vorstellung davon hat, wie aufwändig die drei umgesetzten Features relativ zu den noch ausstehende sieben waren.

In diesem zweiteiligen Artikel zeige ich, wie sich die Planung in Scrum strukturiert durchführen lässt und welche Besonderheiten es dabei zu berücksichtigen gilt. Weiter möchte ich auf typische Fallstricke eingehen, denen man in der Praxis oft begegnet. Ziel ist, die Komponente "Planung" für fortgeschrittene Scrum-Anwender näher zu beleuchten. Der erste Teil stellt kurz das Vorgehen vor und beleuchtet Besonderheiten bzw. Fehler, die häufig in der Praxis gemacht werden. Der zweite Teil beschreibt ausführlich das Vorgehen an einem praxisnahen Beispiel.

Neun Planungsschritte in Scrum

Scrum sieht neun Planungsschritte vor, die sich je nach Zielsetzung in strategische und operative Planung unterteilen lassen (zur näheren Erläuterung s. Abschnitt "Operative und strategische Planung"). Nachfolgend stelle ich die Schritte kurz vor; im zweiten Teil werde ich diese an einem Praxisbeispiel näher erläutern. Die Planungsschritte sind im Einzelnen:

  1. Die Geschäftsführung definiert mit dem Product OwnerProduct OwnerProduct Owner ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) bei Scrum . Der Product Owner ist verantwortlich für das Product Backlog . die Produktvision (strategische Planung).
  2. Der Product Owner definiert die Releaseziele zusammen mit den Stakeholdern (strategische Planung).
  3. Der Product Owner definiert die Sprintziele zur Erreichung des aktuell anstehenden Releaseziels (strategische Planung).
  4. Der Product Owner trägt die benötigten Features im Product BacklogProduct BacklogProduct Backlog ist bei Scrum die Liste aller Anforderungen für ein zu erstellendes Produkt. ein (strategische Planung).
  5. In der ersten Hälfte des Sprint Plannings stellt der Product Owner dem Team diese Ziele vor. Das Team wählt sich eine Untermenge an Features aus dem Product Backlog aus, die es umsetzen will (operative Planung). Ggf. werden die Sprintziele nochmals angepasst oder Features im Product Backlog geändert.
  6. In der zweiten Hälfte des Sprint Plannings plant das Team präzise auf Taskebene, wie es sein Sprintziel erreichen möchte (operative Planung).
  7. Die Planung wird täglich, spätestens während des Daily Scrums, überprüft. Abweichungen werden an den ScrumMaster adressiert und an den Product Owner kommuniziert (operative Planung).
  8. Am Ende des Sprints wird im Sprint ReviewSprint ReviewIm Sprint Review prüft das Scrum Team – ggf. mit weiteren, vom Product Owner eingeladenen, Stakeholdern – am Ende eines Sprints den erzielten Fortschritt und erarbeitet die Grundlagen für das folgende Sprint Planning . Der Scrum Guide betont, dass das Sprint Review informellen Charakter hat und nicht der Berichterstattung über den Projektstatus dient. das Produkt inspiziert. Hier planen Product Owner, Entwicklungsteam und Stakeholder gemeinsam, welche Veränderungen im Product Backlog nötig sind, um das Releaseziel zu erreichen (strategische Planung).
  9. In der Retrospektive wird ermittelt, wie das Team noch effizienter arbeiten kann (strategische Planung).

Wesentliche Voraussetzungen für die Planung

Alle Planungsschritte wiederholen sich regelmäßig in jedem Sprint. Die Anzahl der notwendigen Änderungen variiert allerdings stark: Produktvision und Releaseziel ändern sich wesentlich seltener als die Sprintziele. Trotzdem wird ihre Gültigkeit ständig durch den Product Owner überprüft. Die operativen Planungsartefakte werden jeden Sprint komplett neu erstellt und können täglich im Daily Scrum geändert werden.

Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten
  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.
DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 3
Kommentare 0

Fortsetzungen des Fachartikels

Teil 2:
Vorgehen in der Praxis
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden.