2. Tag SCRUM: Product-Backlog und Task-Planning
Der zweite Tag SCRUM. Wieder ein langer Tag. 70 Epics sind inzwischen bearbeitet. In Summe heute also 42 und damit einige mehr als am Vortag. Hinzu kommt, dass das SCRUM-Team heute die ersten beiden User-Stories bis auf Task-Ebene geplant hat. Die Geschwindigkeit steigt also insgesamt.
Spürbar war eine zunehmende Routine. Es war jedem klar, in welchem Detailgrad Rückfragen gestellt werden mussten, damit User-Stories bewertet werden konnten. Der Prozess des SCRUM-Poker war gelernt. Überraschend war weiterhin, dass manche Stories, die sich vermeintlich einfach darstellten, doch im Einzelfall als sehr komplex betrachtet wurden. Hier brachte der Dialog zwischen den Team-Mitgliedern und mit der Product-Ownerin Klarheit, so dass neu bewertet werden konnte.
Bei Planungen mit Unbekannten (z.B. verschiedene Systeme zur Auswahl und eine Entscheidung liegt noch nicht vor) wurde zunächst mit der komplexeren Annahme kalkuliert. Nachteil: Es gibt eine gewisse Ungenauigkeit, weil die Entscheidung noch fehlt. Vorteil: Es gibt eine erste Kalkulation der Komplexität auf die sich aufbauen lässt.
Dennoch gab es User-Stories bei denen Schnittstellen-Abhängigkeiten bestanden, die im SCRUM-Team nicht geklärt werden konnten, weil die Kompetenzen fehlten, die die Komplexität hätten bewerten können. In diesen Fällen gibt es nur zwei Möglichkeiten: 1. Die nötige Kompetenz in das SCRUM-Team holen oder 2. Eine Person aus der Runde (SCRUM-Team-Mitglied, Product-Owner oder SCRUM-Master) bestimmen, die die notwendigen Informationen einholt, damit die Komplexität bewertet werden kann. Im Extremfall muss ein paralleler Strang eröffnet werden, der neben dem SCRUM-Prozess abläuft und dem SCRUM-Team zu einem abzustimmenden Zeitpunkt zuliefern muss. Dies erhöht die Komplexität und auch das Projekt-Risiko, da Abstimmungen erforderlich werden und Abhängigkeiten entstehen.
Es hat sich bewährt im Hintergrund ein Mindmap zu führen. Darin habe ich als SCRUM-Master Notizen zur Verbesserung des Prozesses gemacht, Rückfragen notiert, Dinge eingetragen, die ich noch beschaffen muss und heute im Speziellen Ergänzungen zur Definition of Done-Liste durchgeführt.
Definition of Done-Liste
In der Definition of Done-Liste werden Kriterien definiert, die geprüft werden müssen, bevor eine User-Story als abgeschlossen gelten kann. Die Prüfung führt das Team selbst durch. Zu den Kriterien gehören beispielhaft „Wurde der Styleguide eingehalten?“, „Wurde eine Dokumentation nach vorgegebenen Kriterien angefertigt?“, „Wurden Tests in verschiedenen Browsern durchgeführt?“. Die Liste der Definition of Done umfasst in unserem Fall inzwischen 10 Prüfpunkte. Der Coach empfahl, die Definition of Done-Liste als Plakat ausgedruckt in den Projekt-Raum zu hängen, damit sie für jeden gut sichtbar ist.
Exemplarisch wurden heute die ersten beiden User-Stories bis auf Task-Ebene herunter gebrochen. Dies diente dem Zweck, eine Relation zwischen erwartetem Zeitaufwand und geschätzter Komplexität zu erstellen. Das Team legt fest, welche Tasks erledigt sein müssen, damit eine Story umgesetzt ist. Eine Bedingung ist, dass es sich nur um Tasks handelt, die vom SCRUM-Team bearbeitet werden können. Dinge, die außerhalb des Teams erledigt werden müssen, unterliegen dem klassischen Projektmanagement. Ziel ist es, so wenig Tasks wie möglich außerhalb des SCRUM-Teams zu erledigen, da dies die Komplexität und das Risiko erhöhen würde. Eine zweite Bedingung ist, dass sich ein Task stets innerhalb eines Arbeitstages erledigen lassen muss (ein Arbeitstag in SCRUM entspricht acht Stunden). Wenn diese Bedingung nicht erfüllt ist, sollte der Task weiter heruntergebrochen werden.
Dieses Task-Planning war im Nachhinein sehr wertvoll. Plötzlich wurde sichtbar, dass zwei Stories von der eine mit einer Komplexität von 3 und die andere mit 8 bewertet waren jeweils mit 17 bzw. mit 18 Stunden Aufwand bewertet wurden. Es wurde offensichtlich, dass die Komplexität der 8er-Story offenbar deutlich überschätzt wurde. Im weiteren Verlauf diente dieses Task-Planning dazu, dass die heruntergebrochenen Stories als Referenz verwendet werden konnten, um nachfolgende Stories besser bewerten zu können.
Task-Planning
Zu jedem Task wird eine Task-Karte erstellt, die im wesentlichen den Namen des Tasks, eine stichwortartige Beschreibung der geplanten Maßnahmen sowie den Zeitaufwand in Stunden umfasst. Beim Festlegen der geplanten Stundenzahl fand ein erneutes Verhandeln – ähnlich dem SCRUM-Poker statt. Hier hätte ich mir als SCRUM-Master erneut Karten wie beim SCRUM-Poker gewünscht, die beim Festlegen der Stunden allerdings nicht vorgesehen sind. Mit den Karten wäre die Festlegung der Stunden evtl. schneller gegangen – zumindest bei der ersten Story. Bei der zweiten Story ging es bereits recht zügig. Auch hier setzte wieder ein rascher Lerneffekt ein.
Ein weiterer Vorteil des vorgezogenen Task-Plannings (das streng nach Regel erst im Sprint-Planning II erfolgt wäre…) besteht darin, dass man erste Anhaltspunkte hat, wie die geschätzten Komplexitätspunkte aller User-Stories im Verhältnis zum geschätzten Zeitaufwand stehen. Theoretisch könnte man nun die Summe aller erwarteten Komplexitätspunkte nehmen und mit dem exemplarisch ermittelten Zeitwerten multiplizieren. Dass hier weiterhin Ungenauigkeiten bestehen, ergibt sich aus dem Beispiel der oben beschriebenen beiden Stories mit 3er- und 8er-Komplexität. Dennoch stellt dieses Verfahren eine Schätzmöglichkeit dar, die im Laufe des SCRUM-Prozesses zunehmend genauer wird.
Für mich habe ich als Lesson Learnt mitgenommen, dass es gut investierte Zeit ist, sich bei der ersten User-Story-Erstellung, und -Bewertung sowie dem ersten Task-Planning Zeit zu nehmen, um alle Fragen zu beantworten. Danach geht es deutlich zügiger voran und das SCRUM-Team wie auch der Product-Owner gewinnen Vertrauen in das Verfahren (der SCRUM-Master selbst auch :-)).
Ich bin gespannt auf Tag 3!
Zugang zu weiterführenden Informationen, zu 150+ Projektmanagement-Vorlagen, Checklisten, eBooks und vielem mehr erhalten eingeloggte Kunden bei Klick auf den folgenden Button:
