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 Entscheidungen treffen darf, kann er seine Rolle korrekt ausfüllen. Ähnlich verhält es sich mit dem Entwicklungsteam: Nur wenn es ohne äußere Einflussnahme wählen kann und darf, wie viele Features es im anstehenden Sprint umsetzen möchte, ist es fähig, nach Scrum zu arbeiten.

Scrum lernt

Scrum ist ein empirisches Modell – es lernt aus der Vergangenheit. Das bedeutet auch, dass mit der Zeit die Prognosesicherheit steigen wird. Ein eingespieltes, erfahrenes Team, das an einem Produkt arbeitet, das es kennt, liefert letztendlich auch sehr verlässliche Vorhersagen darüber, wie viele Features es in einem Sprint schaffen wird. Kennt sich das Team jedoch nicht und ist auch das Produkt für die Entwickler neu, so ist eine Vorhersage in der Regel äußerst ungenau. Optimieren Sie Ihre Prognosesicherheit, indem Sie ein erfolgreiches Entwicklungsteam zusammen lassen und auch das Produkt, an dem dieses Team arbeitet, nur dann ändern, wenn dies unter Berücksichtigung aller Faktoren unbedingt notwendig ist.