Um das gesamte Backlog zu schätzen, musst Du viel Zeit investieren. Vor allem, wenn das Backlog aus vielen neuen Epics oder User Stories besteht. Wie Du es schaffen kannst, das gesamte Backlog in 60 Minuten zu schätzen, erfährst Du in diesem Beitrag.
In diesem Beitrag wird ein Schätzverfahren vorgestellt, mit dem Du das gesamte Backlog schätzen kannst. Das Schätzverfahren ist angelehnt an Magic Estimation. Allerdings wird das Magic Estimation für den Remote-Einsatz umgebaut.
Vorbereitung zum Schätzen des gesamten Backlogs
Vorbereitung: Die User Stories im Backlog müssen bereits vorhanden sein. Die Stories übernimmst Du dann für die Durchführung in ein Online Kollaborationstool (z.B. Conceptboard). Zudem solltest Du die Story Points Wertetabelle in dem Tool abbilden. Dabei kannst Du auch gerne die bisherigen Referenzstories mit angeben.
Dem Team muss zum Zeitpunkt des Schätzens also bereits klar sein, was Story Points sind und wie man sie einsetzt. Auch muss mit dem Team bereits die Story Point Wertetabelle erarbeitet worden sein. Es bietet sich zudem an, wenn das Team auch bereits erste Erfahrungen mit dem Story Points-Schätzen gesammelt hat. Andernfalls müsste zunächst ein gemeinsames Verständnis vom Umgang mit Story Points geschaffen werden.
Backlog Refinement zur Optimierung des Backlogs
Das Magic Estimation kann im Rahmen eines Backlog Refinements oder eines Estimation Meetings stattfinden. Für das Schätzen von bis zu 100 User Storys sollte eine Zeit von max. 60 Minuten vorgesehen werden.
Am Ende des Prozesses wird eine Übersicht über das Backlog entstehen. Ein Beispiel* eines solchen Ergebnisses kannst Du im folgenden Screenshot sehen:
* Am Ende des Artikels gibt es eine Vorlage zum Aufbau der Tabelle.
Ziele der Schätzrunde
- Verständnis über das aktuelle Backlog schaffen
- Wissenslücken im Team identifizieren
- Einen Überblick über das Backlog schaffen
- User Stories für weitere Refinements kennzeichnen
Rahmenbedingungen für das Remote Magic Estimation
- Dauer: 60 Minuten
- Anzahl User Stories: 20 bis 100
- Teamgröße: 3 bis 10 Developer
- Moderation: Scrum Master
Bedingungen für das Schätzen des gesamten Backlogs
- Keine Diskussionen während des Schätzens
- Raum für Diskussionen setzen im späteren Verlauf, doch auf 2 Minuten / Story beschränken
- Story Points werden nach dem Meeting übertragen (in Jira oder welches Online Projektmanagement Tool dafür verwendet wird)
- Die Stories werden nicht heruntergebrochen. Sind sie zu grob, werden sie mit 100 geschätzt.
- Es werden keine neuen Stories erstellt
Remote Magic Estimation Schritt für Schritt
Einleitung: Stelle den Prozess vor und erläutere, dass zunächst Schritt 1 durchgeführt wird. Stelle das Ziel der Magic Estimation vor und die Rahmenbedingungen, unter der das Schätzverfahren durchgeführt wird. Anschließend können die nachfolgenden Schritte durchlaufen werden:
Schritt 1: Überblick verschaffen
Dazu werden alle Teilnehmenden eingeladen, sich die User Stories durchzulesen. Zudem solltest Du bereits hier jede(n) Teilnehmer:in dazu auffordern, sich eine User Story für die Schätzung mit Story Points herauszupicken.
Schritt 2: Je eine Story nacheinander schätzen
Jede(r) Teilnehmer:in nimmt sich eine User Story, verschiebt sie in einen User Story-Bereich und erklärt es kurz (30 Sekunden). Rückfragen, Unklarheiten oder Anmerkungen zur Schätzung können durch Scrum Master oder Product Owner direkt in der User Story hinterlegt werden. Achte allerdings darauf, dass es nicht zu Diskussionen darüber führt.
Schritt 3: Die übrigen Stories schätzen
Alle arbeiten parallel und verteilen die übrigen User Stories, bis alle Stories verteilt sind. Dabei sollen sich die Teilnehmenden gerne auf die Stories fokussieren, über die sie bereits Bescheid wissen. Eine Timebox wird nicht zwingend benötigt. Wenn fertig, dann fertig. Sollte der Prozess aber zu lange dauern und einige User Stories ungeschätzt bleiben, brich den Vorgang nach eigenem Ermessen ab. Das kann z.B. nach 15 Minuten der Fall sein. Die übrigen User Stories werden dann auf die 100 geschoben.
Schritt 4: Unklarheiten durch Sticker markieren
Dazu werden alle Stories durch die Teilnehmenden durchgegangen und Aufkleber vergeben, wenn eine Positionierung nicht passt (10 Minuten). Das bedeutet, Du bereitest Aufkleber für jeden Teilnehmenden vor. Gerne je Person eine Farbe, damit der Aufkleber im Nachgang noch nachvollzogen werden kann. Wenn die Teilnehmenden Fragen haben oder eine User Story anders einschätzen würden, dann sollen sie den Aufkleber draufkleben. Weiterhin soll keine Diskussion stattfinden.
Schritt 5: Die Stories mit Aufkleber besprechen
Hierbei werden beginnend bei der kleinsten Story Point Zahl die User Stories einzeln besprochen, die mit einem Aufkleber versehen waren (2 Min. / Story). Unklarheiten und Rückfragen werden geklärt und das Team soll sich auf eine gemeinsame Story Points Schätzung einigen. Wenn zu viele Unklarheiten auftauchen und das Team sich nicht innerhalb der 2 Minuten einigen kann, dann kann die User Story auf die 100 verschoben werden.
Alle nicht besprochenen User Stories werden in den nachfolgenden Backlog Refinements besprochen. Ebenso die User Stories, die mit 20 oder mehr Story Points geschätzt worden sind. Diese müssen weiter spezifiziert und heruntergebrochen werden.
Das passiert nach der Schätzrunde
Als Product Owner wirst Du Dir vor allem die Stories ansehen, die in den kommenden Sprints drankommen sollen. Sind da User Stories mit einer sehr hohen Story Points Zahl geschätzt worden, sind das Kandidaten für das nächste Backlog Refinement Meeting.
Andernfalls arbeitest Du die unklaren User Stories der weiteren Priorität bzw. Reihenfolge ab. Konkret kann das bedeuten, dass User Stories heruntergebrochen oder näher beschrieben werden. Und im Rahmen eines nächsten Backlog Refinements oder Estimation Meeting erneut durch das Team besprochen und geschätzt werden.
Vorlage für den Aufbau der Magic Estimation
In der ersten Zeile stehen die Story Points. Das Team sollte sich dazu im Vorfeld bereits über eine Reihenfolge und eine Wertetabelle geeinigt haben.
Die zweite Spalte beinhaltet Referenzstories. Diese hat das Team aufgrund der fertiggestellten Stories in vorangegangenen Sprints ermittelt und der Story Point Wertetabelle zugeordnet.
In der untersten Zeile werden alle User Stories platziert, die in der Schätzrunde zu den Story Points zugeordnet werden.
Das könnte Dich auch interessieren:
- Die 3 Scrum Rollen im agilen Projektmanagement
- Aufgaben Scrum Master und Product Owner
- Wie Product Owner Jira verwenden
- Verantwortung als Product Owner
