Scrum-Projekte planen mit System

Teil 1: Besonderheiten und Voraussetzungen
Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle 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 Fehler 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 Zeitpunkt 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 Ziel gestartet wird oder keinerlei Aufwandsschätzung 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 Owner 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 Backlog 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 Review 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.

Jeder muss seine Rolle ausführen können

Übergreifend gilt für alle oben beschriebenen Schritte, dass für eine erfolgreiche Planung die richtigen Fähigkeiten an den richtigen Stellen vorhanden sein müssen. Das bedeutet, dass die Rollen mit dafür geeigneten Personen besetzt und diese zur Erfüllung ihrer Aufgaben auch ermächtigt werden müssen. Nur wenn ein Product Owner beispielsweise

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 7 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link