So schätzen Sie den Aufwand von Backlog Items mit Punkten mit Planning Poker und Magic Estimation

Den Aufwand von Backlog Items in Scrum sollte geschätzt werden, damit ein Scrum-Team weiß, wie viele von diesen es im nächsten Sprint umsetzen kann. Die Developer schätzen den Aufwand im Estimation Meeting. Dies kann mit verschiedenen Methoden gemacht werden. In diesem Artikel zeige ich Ihnen, wie Sie mit Punkten schätzen und Sie lernen eine der bekanntesten Schätzmethoden bei agilen Projekten kennen, Planning Poker und eine der effizientesten Methoden, Magic Estimation. Machen Sie den nächsten Schritt und vertiefen Sie Ihre Scrum-Kenntnisse!

Mit Punkten schätzen

Im Artikel So schätzen Sie den Aufwand von Product Backlog Items in Scrum haben Sie gelernt wie Sie ein Estimation Meeting durchführen. Die wichtigste Aktivität darin ist natürlich den Aufwand jedes Backlog Items zu schätzen, nur so wissen Sie, wie viele von diesen Sie im nächsten Sprint umsetzen können.

Anders als bei traditionellen Schätzverfahren wird bei agilen Methoden der Aufwand einer Backlog Items nicht in „Line of Codes“ geschätzt, sondern es werden dafür meistens Punkte (Story Points) verwendet.

Mit Punkten arbeiten ist sehr einfach. Zuerst wird eine Punkteskala festgelegt, mit der geschätzt werden soll. Hier hat es sich bewährt eine nichtlineare Skala zu verwenden, die ungefähr einer Fibonacci-Funktion entspricht. Das heißt, je grösser die Schätzung wird, desto größer wird auch der Abstand zwischen den Schätzwerten. Hier sehen Sie, wie diese Skale aussieht:

1,2,3 . 5 . . 8 . . . 13 . . . . . .20 . . . . . . . . . . . . 40 . . . . . . . . . . . . . 100

Wenn Sie Anforderungen mit Punkten schätzen, dann schätzen Sie den Aufwand immer relativ zu einer anderen Anforderung. Das heißt, Sie schätzen zu Beginn eine kleine Anforderung aus dem Product Backlog, bei der Sie gut wissen wie Sie diese umzusetzen. Anschließend schätzen Sie eine andere Anforderung und schätzen diese in Relation zur ersten Schätzung. Sobald Sie mehr Sie mehr als zwei Anforderungen geschätzt haben, vergleichen Sie bei weiteren Schätzungen die neuen Anforderungen mit bereits vorhandenen Schätzwerten. Dies stellte sicher, dass die Schätzwerte relativ zueinander passen.

Besonders wenn Sie Anforderungen als „sehr groß“ schätzen, z. B. „40“, kann es sinnvoll sein, wenn Sie diese weiter detaillieren und diese in separate User Stories aufbrechen, um eine genauere Schätzung zu erhalten. Dazu lesen Sie mehr im nächsten Abschnitt.

Die Qualität der Schätzungen wird natürlich besser, wenn die Developer die Anforderung gut verstehen und die notwendigen Arbeitsschritte für die Umsetzung kennen.

In den nächsten Abschnitten zeige ich Ihnen zwei Schätzmethoden, mit denen Sie den Schätzprozess effizient durchführen.

Das Problem mit Story Points

Die Schätzung von Stories und Features in Scrum mit Hilfe von Story Points hat mehrere potenzielle Nachteile. Hier ein paar Beispiele:

• Story Points sind von Natur aus subjektiv und können zwischen verschiedenen Teams oder sogar innerhalb desselben Teams im Laufe der Zeit erheblich variieren. Dies kann es schwierig machen, die Konsistenz und Vergleichbarkeit von Schätzungen aufrechtzuerhalten.
• Stakeholder, die mit Story Points nicht vertraut sind, können deren Bedeutung falsch interpretieren.
• Während Story Points bei der kurzfristigen Planung und dem Sprint-Management hilfreich sein können, sind sie für die langfristige Planung und Vorhersage weniger effektiv.
• Teams könnten sich zu sehr um präzise Schätzungen bemühen, anstatt sich auf die eigentliche Arbeit zu konzentrieren.
• Für neue Teams oder Projekte ohne historische Daten kann es schwierig sein, eine Baseline für Story Points festzulegen. Dieser anfängliche Mangel an Kalibrierung kann zu ungenauen Schätzungen und Planungsschwierigkeiten führen.
• Story Points konzentrieren sich oft auf funktionale Anforderungen und vernachlässigen möglicherweise nicht-funktionale Aspekte wie Leistung, Skalierbarkeit oder Sicherheit. Diese wichtigen Faktoren können im Schätzungsprozess unterrepräsentiert sein.

Story Points sind ein nützliches Werkzeug für agile Teams. Wenn sie sich dieser Nachteile bewusst sind, können sie deren Auswirkungen abmildern und fundiertere Entscheidungen über ihre Schätzungspraktiken treffen.

Machen Sie Story-Punkte messbar

Die Story-Schätzungen berücksichtigen Faktoren wie Arbeit, Komplexität, Risiko und Unsicherheit. Der Rohwert von Story Points ist jedoch relativ und lässt sich nicht direkt in Zeit- oder Geldwerte umrechnen. Dies kann zu Problemen führen, wenn Sie aussagekräftige Schätzungen für die Budgetierung und Terminplanung benötigen. Story Points bieten auch kein Maß für den physischen Fertigstellungsgrad, da sie keine physische Maßeinheit haben. Ist ein Story Point Story eine Stunde Aufwand, 30 Minuten Aufwand oder drei Tage Aufwand wert?

Damit Story Points in Unternehmen weitergehend nützlich sind, müssen sie auf kardinale Maßeinheiten wie Dollar und Stunden kalibriert werden, die von den Projektfinanzieren verwendet werden. Diese Kalibrierung hilft bei der Umwandlung von Story Points in ein Format, das die Entscheidungsträger verstehen und effektiv nutzen können. Die Schwierigkeit besteht darin, sicherzustellen, dass diese Kalibrierung über verschiedene Teams und Projekte hinweg konsistent bleibt, da die Interpretationen von Story Points variieren können.

In den nächsten Abschnitten werde ich Ihnen zwei Schätzungsmethoden vorstellen, mit denen Sie den Schätzungsprozess mit Story Point effizient durchführen können.

Planning Poker

Planning Poker® wurde erstmals 2002 von James Grenning verwendet und benannt und später von Mike Cohn in dem Buch „Agile Estimating and Planning“ populär gemacht. Planning Poker ist eine spielerische Art das Estimation Meeting effizient durchzuführen.

Am Anfang bekommt jeder Teilnehmer einen Stapel Planning Poker Karten mit den Werten von 0 bis 100. Die Werte entsprechen der nichtlinearen Skala einer Fibonacci-Zahlenreihe, die Sie bereits kennengelernt haben. Dann stellt der Product Owner die User Story aus den Product Backlog vor. Das Team klärt eventuelle Unklarheiten mit dem Product Owner. Dann bespricht das Team die Schritte, die notwendig sind, die User Story umzusetzen. Jedes Teammitglied wählt dann aus seinem Planning-Poker-Kartenstapel die Karte aus, die dem Aufwand der User Story am besten entspricht und legt diese verdeckt auf den Tisch.

Zeitgleich drehen dann alle Teammitglieder ihre Karten um. Wenn die Kartenwerte stark auseinanderliegen, erklären die Teammitglieder, die am weitesten voneinander entfernt sind, warum sie ihren Wert gewählt haben. Danach wird nochmals geschätzt nach gleichem Ablauf. Oft werden sich die Schätzungen in der zweiten Runde annähern. Ist dies nicht der Fall, wiederholen Sie den Vorgang, bis sich das Team auf einen Schätzwert geeinigt hat. Selten dauert es mehr als drei Runden, um das Ziel zu erreichen.

Wenn das Scrum-Team Planning Poker noch nicht kennt, wird der Ablauf noch recht langsam sein. Sobald aber ein paar Runden gespielt sind, wird es schneller. Wenn Sie Planning Poker effizient machen wollen, dann verwenden Sie eine Sanduhr mit 2 Minuten Dauer für jede Pokerrunde.

Der Moderator macht sich während dem Planning Poker Notizen, die hilfreich sein können, wenn die User Stories programmiert und getestet werden. (Cohn, 2017)

Magic Estimation

Wenn Sie 50 oder 100 User Stories schätzen müssen, dann ist Planning Poker zu langsam. Deshalb verwenden immer mehr Scrum-Teams dafür Magic Estimation, eine Methode die Boris Gloger von Lowell Lindstrom übernommen und verfeinert hat.

Sie brauchen dazu einen Satz Planning Poker Karten, den Boden oder einen großen Tisch und die vom Product Owner vorbereiteten User Stories aus dem Product Backlog. Die Karten mit den User Stories sollten möglichst groß beschrieben sein, damit man diese bei größeren Gruppen auch aus größerer Entfernung noch lesen kann.

Der Product Owner legt die Planning Poker Karten in der Zahlenreihe auf den Tisch oder dem Boden, durch Abstände getrennt, die den Verhältnissen entsprechen:

1,2,3 . 5 . . 8 . . . 13 . . . . . .20 . . . . . . . . . . . . 40 . . . . . . . . . . . . . 100

Es gibt eine wichtige Regel beim Magic Estimation: Während der Durchführung wird nicht gesprochen!

Der Ablauf von Magic Estimation

1. Der Product Owner verteilt die Backlog Item Karten gleichmäßig an das Team.
2. Jedes Teammitglied liest seine Backlog Items, schätzt den Aufwand anhand der Plannnig-Poker-Zahlenreihe und legt die Karten zu den entsprechenden Zahlenwerten auf dem Boden.
3. Wenn ein Teammitglied seine Karten auf die Zahlenreihe verteilt hat, liest es die Karten, die von anderen Teilnehmern ausgelegt wurden. Es verändert die Position einer Karte, wenn es meint, die Karte gehört an eine andere Position. Das machen alle Teilnehmer parallel und ohne sich mit den anderen zu besprechen.
4. Der Product Owner beobachtet das Geschehen. Wenn er sieht, dass eine Karte oft geschoben wird, dann herrschen hier Meinungsverschiedenheiten.
5. Wenn ein Teammitglied nicht weiß, was eine Karte bedeutet, so legt er diese auf die Zahl „100“.
6. Das Spiel ist beendet, wenn sich keine Karte mehr bewegt oder es nur noch „verschobene“ Karten gibt. Auch wenn sich die Teilnehmer langsam abwenden und sichtlich gelangweilt sind, ist das Spiel beendet.
7. Am Schluss schreiben die Teammitglieder die ermittelten Schätzwerte auf die Backlog Item Karten.
8. Karten, die bis zu Schluss bewegt wurden und wo keine Einigkeit herrscht, nimmt der Product Owner zu sich. Diese können mit dem Team gemeinsam besprochen und dann nochmals gelegt und geschoben werden oder der Wert wird mit Planning Poker bestimmt.

Wann Magic Estimation und Planning Poker einsetzen

Viele Teams werden eine Planning-Poker-Sitzung oder Magic Estimation zum ersten mal im Estimation Meeting durchführen, kurz nachdem ein initiales Product Backlog erstellt wurde. Diese Sitzung dient dazu erste Schätzungen zu erstellen, die für die Dimensionierung des Projekts und die Releaseplanung hilfreich sind.

Aufwandschätzung mit Planning Poker oder Magic Estimation werden während der gesamten Projektdauer regelmäßig durchgeführt. Dies, weil immer wieder neue Backlog Items hinzukommen oder bestehende sich ändern. Der beste Zeitpunkt dafür ist das Estimation Meeting, kurz vor Sprintende.

Aufwandschätzung mit verteilten Teams ist etwas aufwändiger. Zum Teil gibt es dafür kostenlose Online-Tools, zum Beispiel für Planning Poker. Dieses finden Sie auf:

https://www.planningpoker.com/

Hier gibt es noch mehr Wissen