In agilen Umsetzungsmethoden schätzen Teams anders als in konventionellen Methoden, denn es geht hier, neben dem Ziel eine möglichst gute Schätzung zu machen, auch darum einen Konsens im Team herzustellen. Eine der beliebtesten Methoden um dies zu erreichen ist der Planning-Poker. Dieser Artikel beschreib
- Was Planning-Poker ist
- Wofür Planning-Poker eingesetzt wird
- Welche Wissenschaftlichen Gedanken hinter den Plannig-Poker-Karten liegen.
- Ablauf des Planning-Pokers
Was ist Planning-Poker?
Planning-Poker oder auch „Scrum-Poker“ genannt ist eine Technik zum Schätzen von Aufgaben und Aufwänden für Feature-Umsetzungen. Ursprünglich für die agile Software-Umsetzungsmethoden entwickelt, wird Planning-Poker so wie agile Umsetzungsmethoden mittlerweile auch in diversen anderen Branchen abseits der IT und der Softwareentwicklung eingesetzt. Die Schätztechnik ist eine konsensuale Methode und basiert auf der Delphi-Schätzmethode bzw. der Wideband-Delphi-Schätzmethode.
Planning-Poker wurde 2002 von James Granning entwickelt und später von Mike Cohn mit seinem Buch „Agile Estimation Planning“ bekannt gemacht und als Marke eingetragen.
Wofür werden Schätzungen gebraucht?
Sprintplanung
Agile Frameworks wie Scrum arbeiten in Sprints. Diese oftmals 2- bis 4-wöchigen Microprojekte müssen geplant, geschätzt, gesteuert und umgesetzt werden. Dazu sind solide Schätzungen notwendig. Da agile Umsetzungsmethoden sehr oft auch konsensuale Umsetzungsmethoden sind, ist es jedoch auch notwendig, die Schätzung und die Planung im Konsens zu erstellen. Dazu wird bei Scrum oft Planning-Poker verwendet.
Refinementmeetings und Sprint-Planning-II
Der Planning Poker wird üblicherweise im Refinementmeeting oder im Sprint-Planning-II in Scrum eingesetzt, um eine gemeinsame Schätzung von Aufwänden durch das Team zu bekommen. Dadurch wird auch ein einheitliches Verständnis der Aufgabe erreicht, welches in weiterer Folge die Umsetzung der Aufgaben vereinfacht.
Budgetierung und Zeitplanung
Aufgrund der Sprintplanungen, der Velocity und des Backlog-Refinements kann dann ein Fahrplan entwickelt und ein Budget grob definiert werden. Diese muss natürlich immer flexibel bleiben können um nicht in eine alte klassische Wasserfallmethoden-Denke zu fallen.
Obwohl agile Projekte das Spannungsdreieck im Projektmanagement auf den Kopf stellen und es nicht möglich ist den Scope und die Zeit und somit das Budget zu fixieren, benötigen Entscheider und Produktmanager dennoch oft einen budgetären Rahmen, um das Produkt wirtschaftlich designen und umsetzen zu können. Würden die Kosten für die Erstellung außeracht gelassen, so könnte das Produkt nicht wirtschaftlich umgesetzt werden und es käme somit zu einem wirtschaftlichen Schaden. Schätzungen sind daher notwendig um Features und damit die Produktentwicklung maßgeblich steuern zu können. Hier kann Planning-Poker eingesetzt werden, um zu sicheren Schätzungen von Aufwänden zu kommen.
Ablauf des Planning-Pokers
- Jedes Teammitglied hat beim Planning Poker ein Deck Planning-Poker-Karten vor sich verdeckt liegen. Es ist dabei wichtig, dass das gesamte Team sich an der Schätzung beteiligt. Das Planning-Poker-Deck besteht normalerweise aus einer modifizierten Fibunacci-Reihe.
- Der Product-Owner stellt dann ein Product-Backlog-Item mit einer Userstory dem Team vor und diskutiert die Aufgabenstellung bzw. das Feature. Die Teammitglieder stellen solange Fragen an den Product-Owner und ergänzen ggf. das Product-Backlog-Item, bis alle Teammitglieder die Aufgabenstellung und das Feature verstanden haben und es keine weiteren Fragen mehr gibt. Diese Präsentation und Diskussion können, je nach Komplexität und Vorbereitung des Product-Backlog-Items, einige Sekunden bis Minuten in Anspruch nehmen, kann aber auch bedeutend länger dauern. Wichtig ist sich hier Zeit zu nehmen und alle Unklarheiten zu beseitigen
- Jedes Teammitglied überlegt sich nun eine Schätzzahl, welches es den Punktzahlen auf den Pokerkarten annähert. Hat ein Teammitglied sich für eine Zahl entschieden so nimmt es diese Karte verdeckt aus seinem Deck und legt diese vor sich verdeckt ab.
- Erst wenn alle Teammitglieder ihre Schätzzahlen mit Hilfe Pokerkarten verdeckt abgelegt haben drehen alle Teammitglieder die Karten gleichzeitig um.
- Nun werden die Karten miteinander verglichen. Es werden vor allem jene Schätzzahlen miteinander diskutiert die besonders hoch oder niedrig sind. Jene Spieler, die diese Randwerte gespeilt haben müssen, alle anderen dürfen einen Kommentar abgeben, wie sie zu dieser Schätzung gekommen sind. Das Team berücksichtigt die gebrachten Argumente und spielt erneut verdeckt den Planning-Poker. Der Planning-Poker wird solange gespielt, bis alle Spieler die selbe Karte mit den selben Schätzwert gezogen haben.
Was sind die Ergebnisse des Planning Pokers
Der Planning Poker liefert folgende Ergebnisse
Verständnis
Das Team entwickelt ein einheitliches Verständnis von User-Stories und Aufgaben durch die Diskussionen, die während des Planning-Pokers stattfinden. Dadurch können sich die Teammitglieder dann im Sprint-Planning auf die Umsetzung dieser User-Stories committen
Schätzung
Ein wesentlicher Bestandteil damit die User-Story im Sprint einplanbar ist und sich das Team auf diese Planung und Umsetzung committen kann, ist dass die Umsetzungsaufwände bzw. die Komplexität der Aufgabe geschätzt wurden. Diese Schätzung ist ein wesentlicher Bestandteil von Scrum und der Hauptgrund warum Planning-Poker eingesetzt wird.
Userstory zu umfangreich oder zu unklar
Es kann während des Planning-Pokers passieren, dass das Team sehr unterschiedliche Schätzergebnisse liefert und sich nicht auf eine Karte einigen kann, oder die Aufgabe so groß ist, dass sie sehr hohe Karten liefert. In diesem Fall diskutiert das Team oft sehr lange und kann sich schwer oder gar nicht einigen. Wenn diese Eigenschaften eintreten, so ist dies ein Indiz, dass die User-Story zu ungenau oder zu groß ist. Der Product-Owner muss dann einschreiten und die User-Story überarbeiten und/oder zerteilen.
Definition of Ready
Um die Häufigkeit ausschweifender Diskussionen minimal zu halten ist es empfehlenswert eine Definition of Ready (auch DoR genannt) vorab für das gesamte Projekt zu definieren. Die Definition of Ready ist ein Vertrag zwischen dem Umsetzungsteam und dem Product-Owner. Die DoR besteht aus einer Liste an Regeln und Eigenschaften, die ein Product-Backlog-Item aufweisen muss um planbar zu sein und in den Sprint aufgenommen zu werden. Das Team sollte sich nur auf Product-Backlog-Items committen, welche die Defintion of Ready erfüllen.
Pokerkarten
Die Poker-Karten des Sets bestehen aus 11 Karten und eine, zwei bzw. drei Sonderkarten. Die Werte auf den Zahlenkarten sind an die Fibonacci-Folge angelehnt. Das festhalten an die Fibonacci-Folge und somit Schätzen auf vorgegeben Schritte hat einige Gründe. Zum einen gibt die Unschärfe zwischen den vorgegebenen Schritten die Realität am besten wieder. Schätzen bleibt immer Schätzen und ist mit einer gewissen Ungenauigkeit verbunden. Das Steigern der Genauigkeit führt zu erheblichen mehraufwänden, welche durch das verwenden von vorgegebenen Abständen am besten verhindert wird. Es ist also einerseits ein Grund um Zeit beim Schätzen zu sparen und andererseits ein Grund um eine Pseudo-Genauigkeit zu verhindern. Die Zahlen in der Fibonacci-Folge haben einen durchschnittlichen abstand von ca. 60%. Dieser Fakt hat den Effekt dass sich der Schätzfehler über das Gesetz der großen Zahlen und den natürlichen Schätzfehler von Expertenschätzungen ausmitteln. Einer Studie zu folge liegt die Schwankungsbreite bei Bottom-Up Expertenschätzungen nämlich bei +/- 30%.
Zusätzlich zu den 11 Karten gibt es oft auch noch eine zwei oder drei Sonderkarten. Diese sind:
- die ?-Karten (sagt aus, dass sich der Schätzer nicht sicher ist)
- die Kaffeetassen-Karte (sagt aus, dass jemand eine Pause braucht)
- und die Unendlich-Karte (sagt aus, dass die diese Story nicht abgeschlossen oder geschätzt werden kann.)
Andere Einsatzmöglichkeiten für Planning-Poker-Karten und andere Schätzmethoden
Estimation-Game
Beim Estimation-Game wird um Zeit zu sparen, ein Stapel von auf Papier geschriebener User-Stories auf den Tisch gelegt und dem Team zum Schätzen gegeben. Das Team hat zunächst die Aufgabe die User-Stories mit einander in Bezug zu setzen und in eine Reihenfolge ihrer Größe zu bringen. Dazu nimmt jeder Developer der Reihe nach eine User-Story vom Stapel, liest den Inhalt laut vor und ordnet die User-Story passend der Größe nach in eine Reihe ein. Der Product-Owner steht dabei dem Team für Rückfragen zur Verfügung und achtet darauf, dass jede Story auch richtig verstanden wurde. Während das Team die User-Stories in eine Reihe bringen, darf nicht diskutiert werden. Derjenige der die Story-Card gezogen hat ist für die Einordnung verantwortlich. Wenn alle User-Stories der Größe nach sortiert sind, werden von der kleinsten zur größten User-Story die Story-Points vergeben. Dazu legt das Team die Planning-Poker-Karten der Reihe nach dort ab, wo eine Gruppe von Story-Karten mit einem Aufwand beginnt und eine andere aufhört. Die vorhergehende User-Story dient dabei immer als Referenz zur darauffolgenden User-Story. Bei der Vergabe der Story-Points darf das Team über die Anzahl der Points diskutieren, die Reihenfolge darf nur in Ausnahmefällen verändert werden, wenn zum Beispiel das Team gemeinsam zu dem Entschluss gekommen ist, dass eine große Abweichung zwischen den Soll- und Ist-Platz der Story in der Liste ist und die Story doch falsch verstanden wurde.
Vorteil:
Aufgrund des nur eingeschränkt zugelassenen Diskussionsspielraums und des Diskussionsverbots in der Sortierphase, ist das Estimation-Game meist schneller als Planning-Poker. Das Estimation-Game eignet sich daher sehr gut für eine grobe initiale Schätzung des Backlogs.
Nachteil:
Das Estimation-Game ist eine ungenauere Methode, das unter umständen auch keinen Konsens im Team erreicht. Daher ist es oft notwendig eine zweite genauere Schätzung durch Planning-Poker durchzuführen.
Magic-Estimation
Die schnellste Methode um zu einer initialen Schätzung des Backlogs zu kommen ist die Magic-Estimation. Dazu werden die auf Papier geschriebenen User-Stories zu gleichen Teilen im Team verteilt. Am Tisch oder auf einem Board an der Wand sind die Planning-Poker-Karten der Reihe nach aufgelegt. Das Team muss nun innerhalb von 10 Minuten alle Kärtchen einer Zahl zuordnen. Während dieser Zeit darf jeder vom Team seine eigenen Karten platzieren und andere Karten verschieben. Während die Zuordnung stattfindet sind keine Diskussionen im Team erlaubt. Der Product-Owner beobachtet den Prozess und nimmt gegebenenfalls User-Stories aus dem Spiel, wenn er merkt, dass sich einzelne Team-Mitglieder bei diesen uneinig sind. Diese herausgenommenen User-Stories werden im Nachgang dann mit dem Team diskutiert und zugeordnet.
Vorteil:
Die schnellste Methode der Zuordnung und Grobschätzung.
Nachteil:
Die User-Stories werden nicht im gesamten Team besprochen. Der Product-Owner kann nicht sicher gehen, dass das Team alle User-Stories auch richtig verstanden hat. Es kann auch sein, dass nicht jeder Developer alle User-Stories sieht und versteht. Somit kann weder ein gemeinsames Verständnis für die Aufgabenstellung noch ein Konsens vorausgesetzt werden. Es braucht daher auf jeden Fall eine zweite Detailschätzung und ein gemeinsames Refinement mit dem Product-Owner.
Fazit
Planning-Poker ist nicht die einzige, aber eine sehr beliebte Methoden um in Agilen Projekten zu Schätzungen zu kommen. Das Zusammenspiel mit anderen wichtigen Mechanismen wie der Definition of Ready ist wichtig, um zu sauberen Ergebnissen zu kommen. Der Vorteil beim festhalten an Schätzungen mit Hilfe vorgefertigter Karten ist aber, dass nicht der Eindruck einer Genauigkeit, die ja nicht existiert, entstehen kann.
Praxisratgeber Digitalisierungsstrategie entwickeln und umsetzen [Link zu Amazon].
[Amazon 9,99€]Weitere Blogs zur Digitalisierungsstrategie
Digitalisierungsstrategie schnell umsetzen |
Inhalt einer Digitalisierungsstrategie |
|
 |
 |
Weitere Buchempfehlungen
[Links zu Amazon]
 |
 |
 |
| [Amazon 34,00 €] | [Amazon 34,99 €] | [Amazon 24,95 €] |
  |
  |
  |
| [Amazon 19,99 €] | [Amazon 25,99 €] | [Amazon 42,00 €] |
Zum Autor:
David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.
https://www.xing.com/profile/David_Theil
https://www.linkedin.com/in/david-theil-1a4190148/
https://www.linkedin.com/groups/8678887
DigitalisierungsCoach 