Planungsmeeting

Der Sprint beginnt mit dem Planungsmeeting und wenn man mal voraussetzt, dass Du vorher das Backlog im Refinement in Ordnung gebracht hast, dann kann eigentlich gar nicht viel schief gehen. Leider passieren oft – auch bei mir – im Planungsmeeting Dinge, die dafür sorgen, dass das Meeting oder eben der Sprint hinterher nicht optimal läuft. 

Doch zunächst einmal: 

Wozu dient das Planungsmeeting überhaupt? Sinn des Planungsmeetings ist es, dass sich Team und Product-Owner auf das nächste auslieferbare Produktbestandteil – also das sogenannte Produkt-Inkrement einigen. 

Das Sprint Planungsmeeting beantwortet also folgende Fragen:

1. Was ist in dem Produktinkrement des kommenden Sprints enthalten?
2. Wie wird die für die Lieferung des Produktinkrements erforderliche Arbeit erledigt?

Sehr oft teilt man das Planungsmeeting daher auch in 2 Teile ein: Das Planungsmeeting 1, in dem gemeinsam mit dem Product Owner das Ziel und die Aufgaben oder Userstories für den nächsten Sprint festgelegt werden und das Planungsmeeting 2, in dem das Team zur Detailplanung übergeht und die einzelnen Teilaufgaben, die so genannten “SubTasks” bespricht und festlegt. Das Ergebnis des Planungsmeetings ist das Sprint-Backlog als Sammlung aller Aufgaben inklusive der SubTasks, die vom Team im anstehenden Sprint umgesetzt werden. Dieses Sprint-Backlog stellt also den Forecast – also die Prognose dar. Das Dev.-Team ist der Meinung, dass es den gewünschten und besprochenen Nutzen erreichen kann. Dabei hat das Team natürlich auch berücksichtigt, dass vielleicht ein Kollege 2 Tage im Urlaub ist und eine Kollegin eine ganze Woche auf einer Schulung…Der Begriff Commitment oder Selbstverpflichtung ist hier gefährlich, da es damit oft zu Fehlinterpretationen kommen kann (also wenn ein Team sich verpflichtet, wird wahrscheinlich hinterher die Suche nach Schuldigen losgehen, falls nicht alle Stories geschafft werden. Das wollen wir hier aber nicht…). Daher übersetze ich Commitment lieber mit  “Bekenntnis”, denn das ist etwas, was aus dem Herzen kommt und keine Pflicht!

Also nochmal die einzelnen Teile:

Im Planungsmeeting 1 beschreibt der PO das Ziel – also genauer den Nutzen – den er gemeinsam mit dem Team im Sprint erreichen will – man diskutiert das gemeinsam und man einigt sich darauf, was man erreichen kann.  Das Team zieht sich die Userstories raus, mit denen das Ziel am besten erreicht werden kann. Notfalls werden noch neue Userstories geschrieben um neuen Erkenntnissen (z.B. aus dem letzten Sprint oder Kundenfeedback) zu berücksichtigen. Großartige Inhaltliche Diskussionen um die Stories sollten nicht mehr vorkommen, denn das wurde bereits im Refinement besprochen. Auch die Schätzung der Aufgaben ist für die meisten Stories schon im Refinement geschehen und sollte nur noch überprüft werden. Am Ende des Planungsmeetings 1 haben wir dann die Liste der Userstories und das Sprintziel. Der PO kann jetzt eigentlich das Meeting verlassen und das Team macht (ggf. noch zusammen mit dem Scrum-Master) alleine weiter. 

Also nochmal, um es zu betonen: der Product Owner beschreibt das Ziel, welches er erreichen möchte aber nicht er, sondern ausschließlich das Dev.-Team bestimmt die Anzahl der Product-Backlog-Einträge für den kommenden Sprint! Denn das Team entscheidet, was machbar ist!

Im Planungsmeeting 2 werden die Userstories vom Team einzeln besprochen und es werden die Arbeitsschritte und Details geklärt, die notwendig sind um den gewünschten Nutzen zu erreichen. Das betrifft insbesondere die technische Umsetzung, die vom Team designed wird und nicht vom PO vorgegeben. Sollten nicht noch gravierende Zeifel aufkommen und man den PO nochmal zur Abstimmung braucht, kann danach der Sprint gleich gestartet werden.

Auch hier nochmal: Die Betonung liegt darauf, dass das Team entscheidet, wie umgesetzt wird und wer was macht. Der Product Owner gibt keine Designvorgaben und niemand ausser dem Dev.-Team selbst entscheidet, wer was macht.

Noch ein kleines Wort zum Sprintziel: Das Sprintziel gibt dem Dev.-Team Orientierung und beantwortet die Frage warum wir das aktuelle Produktinkrement bauen. Es bietet aber auch eine gewisse Flexibilität bei der Umsetzung muss also aus einer gewissen Flughöhe formuliert sein. Bei der Arbeit im Sprint behält das Team das Ziel immer vor Augen. Wenn Du also Scrum-Master bist, solltest Du das Ziel auch ausdrucken bzw. groß und für jeden Sichtbar aufschreiben und am Task-Board aufhängen.

Soweit so einfach…jetzt komme ich mal zum richtigen Leben:

Was das Dev.-Team alles falsch machen kann…

Sind alle im Meeting da? Schlecht ist es, wenn im Planungsmeetings die Leute, die etwas machen sollen oder wollen nicht da sind. Fasse das Planungsmeeting als Pflichtveranstaltung auf! Nur wenn Du dabei bist, kannst du auch gestalten! Es gibt also keine Entschuldigung nicht dabei zu sein, ausser vielleicht Familie, Kinder, Krankheit…

Sind alle während des Sprints verfügbar? Überlege selbst und sage es offen, wenn Du im Sprint nicht voll zur Verfügung stehst, Urlaubstage hast oder auf Schulungen gehst oder zu Messen gehst…Sonst passiert es leicht, dass ihr Euch als Team überschätzt und Euch damit selbst unnötig unter Druck setzt.

Beachte die technischen Schulden: plane immer ein Viertel der Zeit für Bugfixing ein!! Keine Software wird ungestestet ausgeliefert und das ist ein ehernes Gesetz! Daran gibt es nichts zu rütteln!

Keine “Slack-Time” / “Zeitpuffer” – plane immer einen Zeitpuffer für das Tagesgeschäft ein! Es passiert aber immer irgendwas, was nicht planbar ist, es ruft jemand an, man sitzt zusammen, weil ein Teammitglied eine Frage hat, man spricht am Kaffeeautomaten über wichtige Themen usw…Diese Dinge gibt es, es ist Realität und daher muss das im Sprint auch vorgesehen werden. Wird das nicht berücksichtigt, hechelt das Team die ganze Zeit den Aufgaben hinterher und fokussiert sich auf Output. Wenn sich alle nur auf Output konzentrieren, bleibt die Zusammenarbeit und der gemeinsame Austausch auf der Strecke. Fataler Weise leidet damit dann die Nutzenorientierung – also das, was in englisch gerne mit Outcome – also als Auswirkung – bezeichnet wird.

Plane nicht zu detailliert!: im Planungsmeeting wird zwar “feingeplant” aber sei dabei nicht zu granular oder detailverliebt. Wenn du 2/3. der Subtasks planst ist das völlig ausreichend. Es muss nicht alle “minutiös” in Einzelschritte zerlegt werden. Während der Arbeit bist Du als Teammitglied ja auch in der Lage die Tasks, die sich beim “tun” ergeben, neu hinzuzufügen.

Zu detaillierte Schätzungen: Schätze nicht jeden einzelnen Subtask, Du brauchst nur ein Bauchgefühl für die Größe der Dinge und Deine Erfahrung, was Du so schaffst…Schätze nicht um des Schätzens willen, wir wollen hier keine Bürokratie aufbauen – und ein Zeit-Tracking ist auch eher hinderlich (es sei denn, du machst es nur für Dich persönlich, um besser zu werden)

Zu wenig Planung: Führe das Sprintplanungsmeeting 2 mit dem Team in jedem Fall durch. Wenn ihr das weglasst, leidet die Transparenz,  denn hier wird viel Wissen im Team geteilt. Wenn man gemeinsam bespricht, wie man sich die Arbeit aufteilt, haben alle was davon. Wenn nicht – arbeitet ihr nicht als Team, sondern seid Einzelkämpfer in der Gruppe.

Teamleiter…Es gibt keine Teamleiter. Bitte verlass Dich nicht auf einen ggf. auch selbst ernannten Chefprogrammierer, der die Aufgaben schätzt und verteilt. Macht das zusammen, nur so lernst Du besser zusammenzuarbeiten und lernst auch Verantwortung zu übernehmen. du musst selbst Erfahrungen zu sammeln und dann gewinnst Du letzlich auch an Selbstbewusstsein und Standing im Team. Also Raus aus der Komfortzone…mach es selbst!

soweit zum Dev.-Team…nun noch ein paar Worte zum Product Owner im Planungsmeeting, da gibt es auch ein paar Themen, die Du beachten solltest wenn Du diese Rolle einnimmst…:

Was wollen wir eigentlich? Denke als PO immer an das Sprintziel! Ein gutes Sprintziel beantwortet die Frage “Was wollen wir in diesem Sprint erreichen?” Und – es ist nicht ein Befehl von Deiner Seite als Product Owner sondern es wird im Planungsmeeting mit dem Dev.-Team gemeinsam diskutiert und vereinbart. Verstehe das Sprintziel als “Kalibrierung der Erwartungshaltungen von Product Owner und Dev.-Team”.

Macht ihr nicht eigentlich Kanban? Überlege mal, was Du wirklich machst…macht ihr ein Projekt, bei dem es darauf ankommt in einer bestimmten Zeit etwas Neues zu schaffen? Oder arbeitet ihr an unzusammenhängenden Anforderungen, bei denen verschiedene Themen, Systeme oder Bereiche parallel bearbeitet werden? Wenn Du also kein geordnetes, auf ein Ziel ausgerichtetes Backlog hast, sondern eine bunte Liste von Anforderungen, die sich auf unterschiedliche Ziele und Systeme beziehen, ist vielleicht Kanban die bessere Wahl. Mach nicht Scrum, nur weil Dir einer sagt, das machen ja alle!

Akzeptiere keine unfertigen Stories aus dem letzten Sprint, sondern diskutiere mit dem Team, warum etwas nicht fertig geworden ist. Es geht nicht um die Suche nach Schuldigen, sondern darum, dass Du zusammen mit dem Team lernst realistisch zu die Arbeit einzuschätzen. Das braucht Erfahrung und daher ist es nicht schlimm, wenn nicht alle Userstories geschafft werden. Wenn es aber zur Regel wird, dass einfach alle nicht fertigen Stories in den nächsten Sprint geschoben werden, dann plant ihr kontinuierlich falsch. 

Änderungen in letzter Minute, die nicht klar sind und die DoR nicht erfüllen…

Wenn Du als Product Owner in letzter Minute Userstories in das Backlog für den nächsten Sprint schreibst, dann überlege Dir genau, ob das eine gute Idee ist. Warum ist das jetzt so wichtig? – Weil Du dahinter stehst oder weil gerade Dein Boss angerufen hat? Beachte, dass Du das ganze Planungsmeeting sprengen kannst, denn das Team erwartet von Dir Klarheit. Und Du musst in der Lage sein, die Story auf ein Level zu bringen, das die DoR erfüllt. Wenn Du die Anforderung selber nicht verstanden hast, dann besprich das zusammen lieber nochmal mit Stakeholdern und dem Team z.b. im Refinement. Zu dem Begriff DoR komme ich gleich noch…

Fokus auf Output: Drücke nicht zu viele Stories in den Sprint, es geht nicht darum möglichst viele Stories oder Subtasks umzusetzen, es geht darum einen nachhaltigen Nutzen zu schaffen. Also der Fokus liegt auf Outcome!

So…

Generell gibt es dann noch ein paar Themen, die alle – also das gesamt Scrum-Team – betreffen:

Variable Sprint-Längen: Ändere nicht die Sprintlänge, wenn ihr nicht mit allen Stories fertig werdet. Das hat dann nichts mehr mit Scrum zu tun: Legt den Fokus auf das richtige Schneiden der Userstory, so dass die Story in den Sprint passt und passe nicht die Sprintlänge einer unrealistischen Planung an.

Überladene Sprints: bitte, auch wenn es Druck von aussen gibt und es Leute gibt, die wollen, dass ihr in Anführungsstrichen “schneller” werdet. Gib dem Druck nicht nach und überplane den Sprint nicht. (wenn mal ein oder zwei Punkte in den nächsten Sprint fallen ist das nicht schlimm, wenn ihr aber jedes mal 30-40% der Stories quasi automatisch in den nächsten Sprint fallen lasst, dann ist das was faul. Falls Du Scrum-Master bist, wäre das auch ein Zeitpunkt das Vorgehen mal generell zu hinterfragen. Vielleicht wäre hier auch KANBAN die bessere Wahl?…

Dogma: Zum Beispiel beim Thema “DoR”: Die “Definition of Ready” ist eine gemeinsam von Euch besprochene Liste von Eigenschaften, die eine Userstory erfüllen muss und sie stellt quasi das Eingangstor für die Sprintplanung dar. Was die DoR nicht erfüllt, kann normalerweise nicht für den Sprint geplant werden und muss erstmal im Refinement zurechtgeschnitten und geklärt werden…Aber seid nicht zu streng, betreibt hier keine Erbsenzählerei. Die DoR darf kein Freigabeprozess werden (sowas gibt es im klassischen Projektmanagement, gehört hier aber nicht rein!).

DoR ignorieren: DoR haben ihren Sinn. Wenn das Team keine DoR berücksichtigt, kauft es die Katze im Sack. Die Stories sind nicht wirklich klein genug, wurden nicht verstanden – wie soll man dann abschätzen, ob man das im nächsten Sprint schafft oder nicht? Ihr handelt Euch damit nur Probleme ein. Wenn Du Mitglied des Dev.-Teams bis, dränge darauf, dass ihr DoR aufschreibt und auch berücksichtigt.

Planung wird nicht vom ganzen Team durchgeführt. Bitte nichts für “andere Leute” planen. Agiles Arbeiten lebt von der Zusammenarbeit, Transparenz und Gleichberechtigung. Wenn ihr zum Beispiel nur 2 Repräsentanten des Teams die Arbeit für das gesamt Team planen lasst, dann driften wir in alte Zeiten ab, wo es Leute gab, die für andere dachten. (Wenn ihr Scaled Scrum – wie zum Beispiel LeSS einsetzt, ist das natürlich was anderes, aber das ist eine andere Geschichte und eine eigene Podcastfolge wert)

So weit zum Planungsmeeting und was da alles schief laufen oder missverstanden werden kann.. Wenn Du einige Dinge und Verhaltensweisen, die ich hier besprochen habe, in Deinem Projekt wiederfindest, prüfe, ob Du das nicht in den nächsten Retrospektiven abstellen kannst – egal ob Du jetzt PO oder ScM bist. Schaue auch noch mal in den Scrum-Guide, denn da stehen die wichtigsten Sachen drin…

Scrum ist keine evolutionäre Methode, wie Kanban, es ist ziemlich streng. Wenn Ihr Scrum macht, dann müsst ihr euch auch an die Regeln halten, sonst ist es nicht Scrum.

Und damit möchte ich diese Folge abschließen und bedanke mich fürs Zuhören. Ich würde mich sehr freuen, wenn Du über iTunes eine Bewertung abgeben könntest und mir auch gerne Feedback über das Kontaktformular auf meiner Webseite agilophil.de oder direkt in der Podcastsite “agilophil-daily.de” geben könntest.

Und jetzt wünsche ich Dir viel Erfolg bei Deinem nächsten Planungsmeeting 

Tschüß

Dein Frank