Sprint Planning. Von der Vorbereitung bis zur Festlegung des Sprint-Ziels.

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

Der Weg zu einem weltklasse Team ist lang und alte Arbeitsweisen wirken lange nach. Noch immer sind planungsgetriebene Denkmuster sowie die Einteilung unserer Arbeit in Phasen in unseren Köpfen präsent. Wir sind es gewohnt, dass der Planer vor der Arbeit das Denken übernimmt und in der Ausführung dann einfach nur gemacht wird. In Scrum ist das nicht mehr möglich. Die Planung eines Sprints hat daher nicht viel mit dem zu tun, was wir unter klassischer Planung verstehen. In der Praxis finden sich viele dieser alten Muster und Denkweisen fälschlicherweise im Sprint Planning wieder und sorgen nicht selten für Dysfunktionen bei der Ausführung von Scrum. Sie manifestieren sich beispielsweise darin, dass es sich ungewohnt anfühlt, wenn ein Team das Ziel eines Sprints festlegt und nicht ein “Teamleiter”. Ebenso, wenn wir das Gefühl haben, ein einzelner “Verantwortlicher” müsse die Verantwortung für das tragen, was das Team erarbeitet. Wir sind es gewohnt, dass Planen immer auch mit einer Zuweisung von Zuständigkeiten an einzelne Personen einhergeht. Eine Gewohnheit, die der gemeinsamen Verantwortung des Entwicklungsteams als ganzes im Sprint zuwiderläuft. 

 

Aufgrund dieser Andersartigkeit und des hohen Anspruchs an das Entwicklungsteam fällt es uns oft schwer, loszulassen und den Teams den Raum sowie die notwendige Unterstützung und das notwendige Vertrauen für diese Art der Arbeit zu geben. In der Folge “Sprint Planning” gehe ich genau auf diese Problematik ein und zeige anhand des Rollenverständnisses von Scrum, was die Intention des Sprint Plannings ist und wie ein Planning vorbereitet (Product Backlog, Definition of Ready) und ausgestaltet (Sprint-Ziel, Auswahl der Items) werden kann, damit alle mit einem guten Gefühl in den Sprint starten können. Aufgrund der fortwährenden Präsenz alter Muster gehe ich dabei auch gezielt auf Schwierigkeiten und Dysfunktionen ein.

Die Vorbereitung des Sprints

 

Um klar herauszustellen, wie an ein Sprint Planning sinnvoll herangegangen werden kann, macht es Sinn, die Rollen der einzelnen Scrum-Akteure sowohl in der Vorbereitung als auch bei der Ausgestaltung des Plannings zu betrachten. Darüber hinaus ist es wichtig, den Einsatz einer Definition of Ready und die grundsätzliche Intention des Sprint-Ziels zu verstehen. 

1. Die Scrum Rollen

  • Product Owner (PO):
    Der PO ist für die Pflege des Product Backlogs verantwortlich. Er bereitet das Product Backlog für den Sprint so vor,
    dass es für das Entwicklungsteam informativ ist und Items mit dem größtem Wert erkennbar sind. 
  • Entwicklungsteam (Team):
    Das Entwicklungsteam nutzt diese Informationen, um damit den Sprint eigenverantwortlich auszugestalten,
    sodass es qualitativ hochwertige Ergebnisse erzeugen kann. 
  • Scrum Master (SM):
    Der SM sorgt dafür, dass Team und PO eine Umgebung haben, in der dieses Zusammenspiel gut funktioniert.
    Er sorgt dafür, dass Scrum Events stattfinden und fördert das Zusammenspiel und den Austausch durch diverse (Moderations-) Techniken.  

Auch wenn die Rollen im Scrum Guide klar geregelt sind, ist die Umsetzung nicht trivial. Häufig werden in der Praxis die einzelnen Rollen und die damit verbundenen Aufgaben hinterfragt. Bei einer genaueren Betrachtung der Funktion des Scrum Masters zeigt sich ganz besonders deutlich, warum es wichtig ist, die urspüngliche Intention der einzelnen Rollen zu wahren. Beispielsweise wird oft danach gefragt, warum nicht der PO anstelle des Scrum Masters die Organisation und Moderation des Sprint Plannings übernehmen kann. Dies ist besonders deswegen nicht sinnvoll, weil der Product Owner nicht unbefangen ist. Wenn der Druck, ein Produkt zu liefern sehr hoch ist, könnte es leicht passieren, dass seine Moderation dazu führt, dem Team unrealistische Pläne “aufzudrücken”. An dieser Stelle ist es aber wichtig, ein unabhängiges Feedback zu erhalten, um frühzeitig Probleme zu erkennen und die Zeit und das Budget zum Inspizieren und Adaptieren nutzen zu können. Es macht keinen Sinn, unrealistische Pläne zu lange aufrecht zu erhalten, nur um den Erwartungen anderer (z.B. der Stakeholder) gerecht zu werden. Um dieses unabhängige Feedback zu erhalten, fällt es in den Aufgabenbereich des Scrum Masters, sich um das Stattfinden und die Zweckerfüllung der Events sowie der Aufrechterhaltung des Zusammenspiels zu kümmern.  Eine Mischung der Rollen schafft Dysfunktionen, weshalb klar davon abgeraten werden kann.

Der Scrum Master sorgt dafür, dass die Vorbereitungen des Sprints gut verlaufen und der Austausch zwischen Team und PO stattfinden kann. Er stellt sicher, dass das Team nach der Planung des Sprints flüssig und fokussiert an sinnvollen Aufgaben arbeiten kann. Der Product Owner kann und muss sich in der Vorbereitung und im Sprint Planning voll und ganz auf das Refinement und die Priorisierung der Product Backlog Items konzentrieren und dafür sorgen, dass diese sinnvoll abgearbeitet werden können. Das bedeutet, er muss die Backlog Items so vollständig wie möglich erfassen, diese gemäß ihres Wertes für die Organisation priorisieren und dem Team ausreichend viele Optionen zur Verfügung stellen. 

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 dem Entwicklungsteam 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. Mehr als ein Motto: Ein Sprint-Ziel gibt Orientierung 

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.

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. 

Das Sprint Planning: Ein Deal zwischen PO und Team, in dem „Was“ und „Wie“ festgelegt werden.

 

Der wichtigste Punkt, der die Natur des Sprint Plannings ausgestaltet, zeigt sich im Verhältnis zwischen PO und Entwicklungsteam. Es lässt sich als eine Art impliziten “Deal” beschreiben, bei dem beide Parteien ein Ziel festlegen, das im Sprint erreicht werden soll. Für das Team bedeutet das, eigenverantwortlich zu arbeiten, den PO allerdings in die Arbeit mit einzubinden. Dazu gehört, dass es sich bei Fragen oder relevante Änderungen rechtzeitig und proaktiv an ihn wendet, sodass es keine Überraschungen für den PO selbst oder gar für die Stakeholder gibt. Der PO lässt dem Team genügend Freiraum bei der Festlegung des Arbeitsumfangs, der Herangehensweise sowie auch bei der Arbeit selbst. Ein Mikromanagement seitens des PO sollte nicht notwendig sein. 

Das Resultat aus dem Deal zwischen Team und PO ist ein Forecast an Arbeit, die das Entwicklungsteam in einem Sprint umsetzen möchte. Das Team garantiert zwar nicht das Ergebnis, ist jedoch aus diesem Forecast an Arbeit “commited”, die Verantwortung für den Sprint zu übernehmen. Es sichert zu, das Sprint-Ziel eigenverantwortlich und unter Einziehung des POs zu erreichen. Demnach gibt es zwei Fokuspunkte, die die Planung eines Sprints auszeichnen: Das Was und das Wie

  1. Was: Es gilt, ein Sprint-Ziel zu formulieren und dafür die passenden Backlog Items in sinnvollem Umfang zu wählen
  2. Wie: Es gilt, ein klares Verständnis darüber zu schaffen, wie das Team anfangen kann, die Items zu bearbeiten 

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. 

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.  

  • Unabhängige Auswahl von Items durch das Team
    Das Backlog wird gut sichtbar an einer Wand präsentiert. Hierbei ist wichtig, dass genügend Items platziert werden, sodass das Team eine gute Übersicht und genügend Optionen zur Auswahl hat. Jedes Teammitglied erhält daraufhin einen Post-It und ist aufgefordert, diejenigen Items zu markieren, die seiner Meinung nach im kommenden Sprint zu schaffen sind. 

Die Technik hat meiner Meinung nach drei Vorteile: Sie ermöglicht es uns erstens, alle Teammitglieder zu “hören” und regt zweitens zu einem Gespräch an. Drittens schafft sie es, dass das Team sich nicht blind auf Kapazitäten oder Velocity verlässt

Herunterbrechen der Items in einzelne Tätigkeiten

In der Ausgestaltung des “Wie” brechen die meisten Teams mit denen ich arbeite, ihre Backlog Einträge noch einmal in Tätigkeiten herunter. Sie erzielen dadurch, dass sie mit einer übersichtlichen Anzahl an Backlog Items (meine Faustregel sind 5 bis 10) gemeinsam alles im Blick haben und gleichzeitig durch detaillierte Tasks die konkrete Arbeit im Sprint sichtbar machen und koordinieren können.

Dies sorgt zum einen für Transparenz bei der Arbeit, zum anderen schafft es allen Beteiligten einen Überblick und ermöglicht das eigenverantwortliche Arbeiten als Team

Scrum Sprint Planning Checkliste

Es macht Sinn, dafür ein visuelles Task Board zu nutzen, das neben den priorisierten Backlog Items eine weitere Ebene an Tätigkeiten enthält, die mit einem einfachen Status gekennzeichnet sind: “to do”, “in Arbeit”  oder “done”. Das Team hat damit die Möglichkeit, diese weitere Ebene an Tasks jederzeit zu überblicken (mehr zum Thema Task Board findet ihr hier).  

Und damit fürs nächste Planning nichts in Vergessenheit gerät …

 

… ist mein Tipp, sich eine Agenda oder auch eine Checkliste zu schreiben. So kann einfach überprüft werden, ob an alle wichtigen Aspekte des WAS und des WIE gedacht wurde. Ich habe meine Checkliste diesem Beitrag beigefügt, die du als Inspiration zur Planung des Sprints nutzen kannst. 

Zusammenfassung

In der Praxis finden sich im Sprint Planning fälschlicherweise viele alten Muster und Denkweisen wieder und sorgen nicht selten für Dysfunktionen bei der Ausführung von Scrum. Unter Einbeziehung des Rollenverständnisses in Scrum wird deutlich, was die eigentliche Intention des Sprint Plannings ist. Eine Vorbereitung des Plannings ist besonders in Hinblick auf die adäquate Darstellung des Product Backlog wichtig. Dem PO kommt hier eine wichtige Rolle zu. Bei der Ausgestaltung des Plannings (Sprint-Ziel, Auswahl der Items) ist es entscheidend, dass das Team unabhängig und eigenverantwortlich Feedback gibt und entscheidet, was in den Sprint aufgenommen wird und was nicht. Das Ergebnis ist ein impliziter Deal zwischen PO und Team,  das sich auf ein gemeinsames Sprint-Ziel „committed“, es eigenverantwortlich bearbeiten und unter Einbeziehung des POs erreichen möchte. Die Ausgestaltung des Sprint Plannings kann durch unterschiedliche Techniken effektiver gestaltet werden werden, damit alle mit einem guten Gefühl in den Sprint starten können. 

Ich hoffe, ich konnte dir mit meinen Tipps neue Impulse und Ideen für die Vorbereitung und Ausgestaltung des Sprint Plannings geben. Hast du Fragen oder Anmerkungen? Ich freue mich immer über ein Feedback.

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events, Artefakten und Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training

 

Schreibe einen Kommentar

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen