gesamte Backlog schätzen

Gesamtes Backlog schätzen Online

Um das gesamte Backlog zu schätzen, müssten Sie viel Zeit investieren. Vor allem wenn das Backlog aus vielen neuen Epics oder User Storries besteht. Wie Sie es schaffen, das gesamte Backlog in 60 Minuten zu schätzen, erfahren Sie in diesem Beitrag.

In diesem Beitrag wird ein Schätzverfahren vorgestellt, mit der Sie das gesamte Backlog schätzen können. 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 übernehmen Sie dann für die Durchführung in ein Online Kollaborationstool (z.B. Conceptboard). Zudem sollten Sie die Story Points Wertetabelle in dem Tool abbilden. Dabei können Sie 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 Stories 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 können Sie im folgenden Screenshot sehen:

Magic Estimation in Conceptboard
Magic Estimation im Conceptboard durchgeführt

* 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: Stellen Sie den Prozess vor und erläutern Sie, dass zunächst Schritt 1 durchgeführt wird. Stellen Sie 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 sollten Sie 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. Achten Sie 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 benötigen Sie nicht zwingend. Wenn fertig, dann fertig. Sollte der Prozess aber zu lange dauern und einige User Stories ungeschätzt bleiben, brechen Sie 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, Sie bereiten 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 werden Sie sich 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 arbeiten Sie 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

Template für den Aufbau der Spalten und Zeilen in 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 Sie auch interessieren:

Patric Eid

Patric Eid

Als selbstständiger Projektberater und Trainer verhelfe ich Unternehmen zu mehr Klarheit und Struktur in ihrem Projektmanagement. Zudem unterstütze ich Projektleiter:innen und Product Owner in der 1:1-Arbeit als Agile und Business Coach. Meine Themenschwerpunkte sind Projektmanagement und Anforderungsmanagement. Zudem führe ich Anwender-Schulungen beispielsweise mit Jira, Confluence oder pqforce durch. Meine Seminare haben aufgrund von umfangreichen praktischen Erfahrungen in unterschiedlichen Branchen und Projektrollen einen hohen Praxisbezug.
Patric Eid

Patric Eid

Als selbstständiger Projektberater und Trainer verhelfe ich Unternehmen zu mehr Klarheit und Struktur in ihrem Projektmanagement. Zudem unterstütze ich Projektleiter:innen und Product Owner in der 1:1-Arbeit als Agile und Business Coach. Meine Themenschwerpunkte sind Projektmanagement und Anforderungsmanagement. Zudem führe ich Anwender-Schulungen beispielsweise mit Jira, Confluence oder pqforce durch. Meine Seminare haben aufgrund von umfangreichen praktischen Erfahrungen in unterschiedlichen Branchen und Projektrollen einen hohen Praxisbezug.

Jetzt Klarheit im Projekt gewinnen:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on xing
XING
Share on email
Email

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.