0511 874 590 50 info@agile-im.de
Sie finden den Artikel interessant? Teilen Sie ihn mit Ihrem Netzwerk!

Im Beitrag AIM Agile Planning hatten wir anhand von Jira über die Möglichkeiten zur Planung, Schätzung und Verteilung von Aufgaben berichtet. In der operativen Beratung von Teams begegnen uns aber auch, immer wieder Fragen nach der grundsätzlichen Zielstellung und Best Practices in der Umsetzung.

Das Planning ist neben dem Daily, der Retrospektive, dem Review und natürlich dem Sprint selbst, eins der fünf Events des Scrum Zyklus und aus unserer Erfahrung, dass mitunter am wenigsten beliebte. Nichtsdestotrotz ist es im Hinblick auf die Umsetzung der Produkt-Roadmap, insbesondere für die Kollegen aus den eher klassischen Projekt- und Entwicklungsteams ein fester Ankerpunkt, um zu verstehen, wie sich die zukünftige Arbeit gestalten wird. Wie kommt es nun zu dieser Diskrepanz und welche Maßnahmen können getroffen werden, dass Event für alle Beteiligten sinnvoll und nutzbringend gestaltet werden kann?

Sprint Planning erfolgreich gestalten

Grundsätzlich sollen im Sprint Planning zwei Kernfragen geklärt werden. Zum einen was soll im Sprint erreicht werden und zum anderen wie das passieren soll. Als Input hierfür stehen Product Backlog, der derzeitige Produkt-/Umsetzungsstatus und ggf. bestehende Rahmenbedingungen zur Verfügung. Was und wie resultieren in Sprintziel und Sprint Backlog – so weit so einfach.

Auf die Rückfrage, wie das Planning normalerweise läuft, werden als Kritikpunkte am häufigsten die Länge des Plannings, das fehlende Sprintziel als auch die geringe Wertschätzung des Teams genannt.

Das dauert einfach viel zu lang!

Neben vielen anderen Faktoren tauchen häufig zwei Aspekte auf, die dafür sorgen, dass sich ein Sprint Planning stark in die Länge zieht (und auch wenn dies als Timebox so vorgesehen ist, bedeutet es nicht, dass ein 8 Stunden Meeting für einen 4 Wochen Sprint auch wirklich effizient und konzentriert funktioniert).

Es gab kein Product Backlog Refinement

Ohne das Refinement des Product Backlogs wird das Planning dazu verwendet, ein Review der Roadmap vorzunehmen, User Stories zu priorisieren und gegebenenfalls auch noch zu aktualisieren. Erst mit dieser Vorarbeit ist es aber möglich den Sprint Backlog auszugestalten und das Team aktiv bei den Bedarfsfällen in die Schätzung zu involvieren. Unsere Empfehlung ist es ein Refinement rollierend durchzuführen (jede Woche) und immer die nächsten zwei Sprints zu betrachten.

Es sollen alle Inhalte auf Issue- und Subtask-Ebene abgeschätzt werden

Auch wenn das Refinement durchgeführt wurde und bereits ein Draft des Sprint Backlogs mit ins Meeting eingebracht wird, tendieren insbesondere unsichere Teams (neue Konstellation, neues Produkt, unterschiedlicher Kenntnisstand, reporting lastige Umgebung) dazu alle Unsicherheiten des gesamten Sprints ausräumen zu wollen.

Je nach Komplexität und Teamgröße ist das ein zeitaufwendiges Unterfangen. Einfacher ist es die Aufgaben der ersten Woche konkret und im Detail zu schätzen und damit einen entsprechenden Arbeitsvorrat zu schaffen und durch die Kombination aus Refinements und Daily Plannings im Laufe des Sprints weiter zu konkretisieren.

Tipps vom Profi im Scrum Sprint Planning Web-Seminar

Unser Agile Coach Ulf Daniel zeigt Ihnen anhand von Best Practices und Antipatterns, wie Sie Ihre Scrum Sprint Plannings erfolgreich gestalten können.

Wir haben kein Sprint-Ziel!

Ein Sprint-Ziel ist nicht die Feststellung, dass eine Anzahl X an User Stories mit einer zugrunde liegenden Anzahl Y an Story Points in einem Zeitraum Sprint-Länge Z abgearbeitet wird. Viel mehr definiert ein Sprint-Ziel den Erfolg des Teams und kann sich auf das Produkt(-inkrement), einen Prozess, aber auch einzelne Akteure beziehen. Ein Sprint-Ziel zahlt damit auf den Nutzen des Produktes ein.

Nimmt beispielsweise die Qualität der letzten Inkremente ab, die Entwicklungsgeschwindigkeit ist aber gleichbleiben hoch oder steigt sogar, wäre es neben der inhaltlichen Befüllung des Sprints sinnvoll als Sprint-Ziel zu formulieren, dass in diesem Sprint alle Arbeiten im Peer Programming durchgeführt werden oder dafür zu sorgen, dass neue Teamkollegen inhaltlich besser involviert sind und gecoached werden.

Es werden nicht alle Teilnehmer angehört!

Gerade in Multiprojektumgebungen kommt es vielfach zu kurzfristigen Verschiebungen von Teammitgliedern und damit zu Neukonstellationen und unterschiedlichen Wissensständen hinsichtlich des Produktes. Dies resultiert zuweilen darin, dass sich eine Art Teamlead im Entwicklungsteam ausprägt, die/der den Dialog mit dem Product Owner übernimmt und bei Ein- und Abschätzung meist die letzte Stimme, mitunter sogar eine Art Vetorecht behält. Gerade unerfahrene Teammitglieder werden unsicher, wie und ob sie ihre Anmerkungen und Fragen noch einbringen können.

Negativ wird dies vor allem dann wahrgenommen, wenn die abgeschätzten Stories, nicht von der Person selbst umgesetzt werden, sondern nach dem Planning bei einem Kollegen verbleiben, der im Meeting selbst seine Rückfragen nicht platzieren konnte, da sich Product Owner und Teamleader ja bereits über das Vorgehen einig waren.

Seltener begegnet uns auch die Konstellation in der der Product Owner selbst schon davon überzeugt ist, dass die Abschätzung durch das Team per se nicht mehr notwendig ist, da das meiste Wissen ohnehin beim ihr/ihm liegt. Dies kann passieren, wenn der Product Owner im Vorfeld lange im Entwicklungsteam mitgewirkt hat oder bei langlaufenden Projekten der Meinung ist, dass die aus dem Projekt zur Verfügung stehenden Metriken (bei uns dauert jede Story ca. 6 Stunden) verlässlicher ist, als alles neu zu diskutieren.

Bis auf wenige Ausnahmen, lassen sich dieses Verhalten durch eine vorausschauende Moderation des Meetings, im härtesten Fall kurzfristige Abschnitte des Meetings ohne Teamlead oder Product Owner abbauen. Wichtig bleibt, dass im Nachgang auch alle Teilnehmer verstehen, dass sie einen Mehrwert geleistet haben und dieser auch von den anderen wertgeschätzt wird.

Haben Sie noch Fragen oder Anregungen zum Scrum Sprint Planning Artikel? Dann kontaktieren Sie mich gerne direkt unter udaniel@agile-im.de

Ulf Daniel

Bereichsleiter & Agile Coach, AIM

Diese Artikel könnten Sie auch interessieren: