SOFA-Talk / Das Sprint Planning in Scrum

Markus Stroh - 23.07.2020

Wie schon häufiger an dieser Stelle möchte ich Erfahrungen aus unserem internen Wissensforum rund um die Themengebiete Scrum / Agile veröffentlichen, um den Austausch rund um Scrum zu unterstützen. In diesem SOFA-Talk (Scrum Open Forum ARITHNEA) widmeten wir uns wieder einem Scrum-Kernthema: dem Sprint Planning.

Auf dem Sofa haben dieses Mal Volker Bogacki (Projektleiter und Vertreter der Scrum Initiative), Marc Hofer (Software-Developer), Kai Mütz (Software-Developer) und ich selbst, Markus Stroh (Scrum Master, Vertreter der Scrum Initiative und Gründer des SOFA-Talks), diskutiert.

Einblicke in die Theorie und Praxis von Scrum erhalten Sie in unserem Whitepaper:

Zum Whitepaper

 

Erster Stopp: Scrum Guide

Unserer Tradition folgend blickten wir in den Scrum Guide und fanden dort – im Vergleich zu anderen Diskussionsthemen – eine solide Grundlage. Nicht nur der Planungshorizont von acht Zeitstunden auf einen 4-Wochen-Sprint ist klar vorgegeben, sondern auch nützliche Hinweise, wie das Vorhandensein einer Kapazitätsplanung, sind darin festgehalten. Klar ist auch, dass das gesamte Scrum Team am Sprint Planning Meeting teilnimmt. Es geht darum zu prüfen, welche Product Backlog Items (bei uns "User Stories" genannt) wir umsetzen können und wie wir zu diesem Ziel gelangen. Dabei darf auch nicht das Sprint Goal vergessen werden, das gemeinschaftlich gesucht und festgelegt wird.

Zwischenstopp: Schon „ready“ für die Planung?

Wir stimmten projektübergreifend zu, dass eine Kapazitäts- und Urlaubsplanung auf jeden Fall vorhanden sein muss, da ansonsten keine sinnvolle Planung möglich ist. Hier wurde bereits deutlich, dass man zwischen Anwesenheit und Verfügbarkeit unterscheiden muss. Wie viel Zeit steht den Entwicklern wirklich zu Verfügung? Auch nach Abzug von Scrum Meetings und weiteren Verbindlichkeiten innerhalb der Firma? Der Unterschied kann sehr deutlich ausfallen und ein erster Stolperstein für einen erfolgreichen Sprint sein.

Damit geplant werden kann, brauchen wir ein priorisiertes und geschätztes Product Backlog. Einige Teams führen diese Abstimmung mit dem Product Owner schon im Vorfeld durch, damit der Planungstag reibungsloser verläuft, während andere Teams diese Sachen am Tag selbst durchführen. Einig waren sich alle, dass die Product Backlog Items „ready“ sein müssen. Es reicht nicht nur eine Überschrift, es braucht abgestimmte Inhalte, Akzeptanzkriterien, API-Dokumentationen und Designs, damit wir auch starten können.

Wer den Planungstag noch weiter entzerren will, kann schon vorab eine grobe Kapazitätsüberprüfung machen und dem Product Owner einen Richtwert mitgeben und schauen, ob es Abhängigkeiten zwischen Anforderungen gibt, die so nicht abgebildet werden können.

 

Hauptstopp: Planning oder auch Task Breakdown

Die Hauptarbeit findet bei uns in den Task Breakdowns statt. Teams treffen sich, schauen über die User Stories und zerschneiden sie in Sub-Tasks. Dabei gehören Standardaufgaben wie Review-Folien, Abnahmen und Backmerges genauso mit dazu, wie die eigentliche Implementierung. Klare Größenvorgaben für Tasks gibt es bei uns kaum, viele orientieren sich jedoch an einem Wert von einem Arbeitstag. Ausnahmen bestätigen auch hier die Regel. Diese Größenordnung kann jedoch helfen, sich selbst und das Team im Daily zu hinterfragen. Warum arbeite ich immer noch am Task von gestern? Brauche ich Hilfe? Haben wir Schwierigkeiten unser Sprintziel zu erreichen?

Hier wurden auch die unterschiedlichen projektbezogenen Rahmenbedingungen deutlich. Ein Team zerschneidet manche User Stories gar nicht. Ein anderes Team schätzt die Tasks danach in Zeitstunden. Wieder andere Teams normieren die Tasks überhaupt nicht und verlassen sich auf Mittelung durch Masse.

Es wird deutlich, dass die Planung hier sehr individuell ist und auch in allen Varianten funktioniert. Es ist abhängig vom Kunden, dem Sicherheitsbedürfnis und der Erfahrenheit der Teams. Für alle Durchführungsoptionen gab es klare Pro- und Kontrapunkte. Es kann hilfreich sein mit verschiedenen Methoden zu agieren und die für sich richtige zu finden.

Endstation: Commitment versus Forecast

Nachdem die Teams geplant und mit den jeweiligen Product Ownern letzte Fragen besprochen wurden, geht es auf die Zielgerade. Es entsteht eine Liste von Product Backlog Items die das Entwicklungsteam innerhalb eines Sprints für machbar hält. Dieses Sprint Backlog wird mit dem Product Owner besprochen, damit ein klares Bild entsteht was das Ziel ist, und warum möglicherweise Themen auch nicht gemacht werden können. Hier bietet sich noch eine Chance, um an den Prioritäten etwas zu verändern. Man sollte sich dann jedoch auch klar darüber sein, warum man diese Prioritäten auf einmal verändert und wie der Impact auf die Vision ist.

Obwohl wir übergreifend die Sicherheit einer vollständigen Sprintplanung bevorzugen, reicht es aus, zunächst die ersten Tage des Sprints zu planen und sich dann von diesem Punkt ab weiter zu bewegen. Für erfahrene Teams bietet das Raum zur verbesserten Agilität, für weniger erfahrene Teams kann das zum Genickbruch werden.

Am Ende können wir uns hoffentlich auf ein Anforderungs-Set verständigen und damit loslegen. Vom Wording her wird „Commitment“ nicht mehr benutzt, sondern durch Forecast ersetzt, denn wir können nur bestmöglich planen und eine Vorhersage treffen, eine Glaskugel besitzen auch wir jedoch nicht. Wird ein Kollege krank, ist ein System nicht verfügbar oder trifft man im Verlauf der Arbeit auf unbequeme Erkenntnisse, dann kann auch ein guter Plan manchmal nicht aufgehen. Dennoch sollte man ein Sprint Forecast als inneres Commitment begreifen. Jeder sollte mit dem Plan und dem Ziel verbunden sein und sein Bestes tun, um Mehrwert für den Kunden zu schaffen.

Missing Link: Sprint Goal

Oft wird es vernachlässigt: das Sprint Goal. Dabei kann es sehr nützlich sein und zwar für alle Seiten. Ein Sprint Goal kann dem Product Owner dabei helfen den richtigen Fokus für den Sprint zu setzen und beizubehalten. Was will er wirklich erreichen? Welche User Stories sollten im Sprint enthalten sein, um seine Product Vision optimal zu entfalten? Darüber zu reflektieren kann auch dem Entwicklungsteam helfen zu verstehen, was erreicht werden soll. Das Team kann dann seine Beratungsfunktion wahrnehmen und dabei helfen dieses Ziel optimal anzusteuern. Das Team wird zum Lotsen und unterstützt den Product Owner auf seinem Kurs.

Take-away

Es gibt viele Varianten der Planung und alle können richtig sein. Wichtig ist, dass man miteinander spricht und die Besonderheiten seines eigenen Teams, des Kunden und des Projektumfeldes in diese Ideen mit einbezieht. Die Grundwerte von Offenheit, Respekt und Transparenz helfen, um den Einstieg in den nächsten Sprint so gut wie möglich zu bewerkstelligen.

 

Tipp: Die Checkliste für Ihren agilen Reifegrad

Sie brauchen Rat hinsichtlich der Qualität Ihres Scrum-Projekts? Prüfen Sie jetzt die agile Reife in Ihrem geplanten oder laufenden Scrum-Projekt und ermitteln dabei zielgerichtet, in welchen Bereichen noch Optimierungspotenziale bestehen. Das geht ganz einfach mit unserer "Checkliste - Agiler Reifegrad".

Zur Checkliste

Tags: Agile Business - Beratung & Strategie - Inside-ARITHNEA

Kommentar

Neueste Blogbeiträge direkt in die Inbox?

newsletter-phone

ARITHNEA Newsletter

Aktuelle Trends, interessante digitale Lösungen, neue Best-Practice-Projekte von ARITHNEA oder Infos über wichtige Branchenevents – mit unserem monatlichen Newsletter sind Sie im Digitalen Business stets up to date.

Jetzt Abonnieren