Sprint Planning

Ist das Product Backlog nicht ausreichend vorbereitet, kann das Planning nicht zielführend abgehalten werden. Ein häufiges Beispiel aus der Praxis ist die spontane Vorstellung neuer Items im Sprint Planning durch den PO. Das Planning wird damit zu einer Überraschungsparty, bei der der Product Owner plötzlich Items vorstellt, die den Entwicklern gänzlich unbekannt sind. Natürlich kann es immer einmal vorkommen, dass Items nachträglich hinzugefügt werden. Dies sollte sich allerdings im Rahmen halten, da das Team beim Hinzufügen von völlig unbekannten Items wenig Handlungsspielraum hat und in letzter Konsequenz diese ggf. nicht in den Sprint mit aufnehmen kann. Darüber hinaus sinkt dadurch die Motivation und es baut sich unnötigerweise Druck auf.

Ein weiteres Beispiel, das dazu führt, dass eine Auswahl an Items im Planning nicht sinnvoll erfolgen kann, ist das Fehlen an Optionen: Das Team benötigt eine Auswahl an Items, die es ihm erlaubt, zu wählen. Fehlende Optionen verringern auch hier wieder den Handlungsspielraum und nehmen dem Team die Möglichkeit, Items in sinnvoller Reihenfolge abzuarbeiten.

2. Sprint-Ziel: Zentraler Orientierungspunkt statt Sprint Motto 

Die Qualität des Product Backlogs beeinflusst die Qualität des Sprint-Ziels. Es ist daher ausschlaggebend für ein gutes Sprint-Ziel. Gut ist ein Backlog dann, wenn es dem Team einen Ausblick auf das übergreifende Gesamtziel bietet. Denn nur wenn ein klares Verständnis vom Gesamtziel gegeben ist, lassen sich Sprint-Ziele sauber daraus ableiten. Darüber hinaus benötigt das Team den notwendigen Kontext, um entweder selbst Vorschläge zu machen, oder die Vorschläge des PO diskutieren zu können.

Es geht bei der Definition des Sprint-Ziels also nicht um die bloße Festlegung eines Bündels an Items, sondern vielmehr darum, diese dem Kontext entsprechend sinnvoll und entsprechend des übergreifenden Gesamtziels zu wählen, sodass es dem Team im Sprint Orientierung gibt. 

Ein fragmentierter, kurzfristiger Ausblick von Backlog Items hat zur Folge, dass in der Praxis häufig sogar das Sprint-Ziel weggelassen wird oder es zwar existiert, aber zu wenig Orientierung gibt. Dies sorgt dafür, dass ein effektives und fokussiertes Abarbeiten der Items erschwert wird.

In dem Artikel Creating effective Sprint Goals gibt Roman Pichler eine ergänzende Perspektive zum Thema.

3. Definition of Ready: Gemeinsames Verständnis von “Fertig” oder Brandschutzmauer?

Aus den Vorzügen, ein gemeinsames Verständnis von Fertig als „Definition of Done“ explizit zu machen, um dadurch die richtigen Themen konsistenter und besser liefern zu können, ist die Idee entstanden, dieses Konzept auch auf finale Backlog Items zu übertragen. Kurz: Die Definition of Ready beantwortet die Frage, ab wann unsere Items gut genug sind, um sie in den Sprint ziehen zu können. Bei der Definition of Ready geht es im Kern darum, ein gemeinsames Verständnis von Fertig zu schaffen, um dadurch für mehr Konsistenz zu sorgen. Darüber hinaus können dadurch Zusammenhänge und Probleme frühzeitig aufgedeckt und aus dem Weg geräumt werden. 

In der Praxis kann dies ganz einfach umgesetzt werden. Ich nutze hierfür gern Labels (bei Papier-Backlogs beispielsweise Post-It’s), um die unterschiedlichen Themen zum Ausdruck zu bringen, die wir bei einer guten Backlog-Pflege im Blick haben sollten. Das können Risiken sein, aber auch Abhängigkeiten oder zugehörige Anforderungen.

Die Kehrseite des Sichtbarmachens von Abhängigkeiten und Risiken ist jedoch, dass das Team nicht selten vom PO fordert, Items in ihrer Komplexität zu reduzieren, bevor diese in den Sprint gezogen werden. Die Definition of Ready wird dann zur “Brandschutzmauer” und es entsteht ein hoher Anspruch an den PO. Eine sehr anspruchsvolle Definition of Ready kann dazu führen, dass ein PO mit seinen “frühen Items” alleine gelassen wird und gezwungen ist, eine Lösung für etwas zu finden, das er alleine gar nicht lösen kann. Eine derartige Entwicklung sollte beseitigt werden, denn die ursprüngliche Intention von Scrum ist es, Risiken oder Abhängigkeiten in der Zusammenarbeit zu betrachten und gemeinsam zu lösen. 

4. Schätzung des Arbeitsumfangs (Kapazität/Velocity)

Zur Ausgestaltung des „Was“ gehört die Schätzung des Arbeitsumfangs. Um festzulegen, was alles im Sprint bearbeitet werden kann, beziehen Teams häufig Hilfsmittel in Form einer Kapazitätsplanung oder des durchschnittlichen Umfangs von Items in einem Sprint (Velocity) mit ein. Das Berechnen von Kapazitäten ist eine gute Praktik um zu erkennen, was das Team in einem Sprint schaffen kann. Die Items können dann in Tasks heruntergebrochen und und auf die verfügbaren Kapazitäten aufgeteilt werden, sodass klar ist, wie viel in einem Sprint bearbeitet werden kann. Dies macht Sinn, wenn wir beispielsweise die Verfügbarkeit einiger Teammitglieder in die Planung miteinbeziehen wollen. 

Es ist allerdings wichtig zu beachten, dass die Berechnung von Kapazitäten nur eine Diskussionsgrundlage darstellt und dass nur das Team selbst entscheiden kann, wie viele Items in einem Sprint platz haben. Denn: wenn wir uns strikt auf Kapazitäten verlassen und uns basierend darauf zu 100 Prozent auslasten, übergehen wir die Tatsache, dass es Themen gibt, die erst im Sprint aufkommen. Beispielsweise kann es passieren, dass wir Risiken falsch einschätzen oder die Wissensverteilung im Team sich verändert hat.Ähnlich verhält es sich mit der Velocity: Wir schließen vom Umfang der Items der Vergangenheit auf die Zukunft. Ein striktes Festhalten an vergangenen Werten macht auch hier keinen Sinn. Kapazitäten sowie Velocity sind agile Tools, die bei der Planung helfen sollen und (wie alle agilen Tool)  nicht nicht für den blinden Einsatz gedacht sind, sondern vielmehr dazu, einen Austausch im Team anzuregen. Ein striktes Festhalten an früheren Schätzungen kann dann dazu führen, dass die Qualität leidet oder, dass das Team aufgrund einer zu hohen Auslastung den Sprint nicht beenden kann.

5. Unterstützende Technik zur sinnvollen Auswahl der Backlog Items

Zur Ausgestaltung des „Was“ gehört auch die Auswahl der Backlog. Diese findet gemeinsam im Team statt. Hier gilt es zu beachten, dass es unterschiedliche Persönlichkeiten und Sichtweisen geben kann, und es wichtig ist, alle zu hören. Um dieses unabhängige Feedback sicherzustellen, können Moderationstechniken angewandt werden. Meinen Favoriten möchte ich gern näher vorstellen.