Aufwandspokerregeln

Einige agile Projektmethoden versuchen über das Bestimmen der Komplexität von Aufgaben Planbarkeit im Projekt herzustellen. Ein häufig gewählter Methodenbaustein zum Ermitteln der Komplexität ist das Aufwandspokern. 

Nach welchen Regeln funktioniert dieser Baustein am Besten?

Aufwandspoker wird sowohl im Extreme Programming (XP) als auch in SCRUM als Methodenbaustein genutzt.

Zur Vorausschau wird das Pokern häufig für das Projekt als solches und während des Backlog Grooming eingesetzt. In jedem Fall ist das Pokern (welches auch Planning Poker® oder SCRUM Poker genannt wird) während der Planung des kommenden Iteration oder Sprints notwendig.

Teilnehmer der Planungen sind die Projektteam-Mitglieder. In einigen Teams hat sich die Regel etabliert, dass auch der Product Owner oder weitere Projektbeteiligte am Planning und damit beim Aufwandspokern teilnehmen. 

Für SCRUM gilt, dass der SCRUM Master das Sprint Planning moderiert. Für einige Teams gilt die Regel, dass der SCRUM Master (d.h. der Moderator oder die Moderatorin der Sitzung) nicht mitpokern darf. Andere Teams sehen den Moderator oder die Moderatorin als Teil des Schätzteams an -- und fordern die Beteiligung beim Pokern mit ein. 

Die Beteiligten sollten genau klären, wer Teilnehmer und Teilnehmerin des Pokerns ist -- und dauerhaft an dieser Regel festhalten. Das Team wird nach und nach lernen, exakte Fragen zu stellen und ein gemeinsames Verständnis der Aufgaben und der Komplexität der Aufgaben zu entwickeln. Dies gelingt nur in einem stabilen Team.

Sofern das eigentliche Team nur aus Entwicklern und Entwicklerinnen besteht, ist die Beteiligung von Projektbeteiligten anderer Disziplinen zu erwägen. Häufig sehen "artfremde" Projektbeteiligte sehr früh die blinden Flecken des Entwicklungsteams, die durch das "Prinzip Hoffnung" entstehen. In interdisziplinär aufgestellten Teams ist dieser Beitrag fest integriert.

Die Teilnehmer und Teilnehmerinnen einigen sich vor der ersten Pokerrunde darauf, welcher Kartenwert für eine mittlere Komplexität steht. Häufig wird für diese eine Referenz-UserStory angegeben. Dies hilft allen Beteiligten die nachfolgend vorgestellten UserStories einzuordnen.

Der Product Owner stellt die UserStory vor. Anschließend wählt jeder der Teilnehmer und Teilnehmerinnen verdeckt eine der Karten aus. Diese werden auf das Signal des Moderatoren oder der Moderatorin aufgezeigt.

Nach welchen Regeln Einigkeit über die Schätzung hergestellt wird, ist Regelungssache. Eine Schätzung wird dann angenommen, wenn

1. alle Beteiligten den gleichen Wert auswählen,
2. eine Mehrheit von 2/3 der Beteiligten den gleichen Wert auswählt oder
3. wenn mit maximal einer Ausnahme (um einen Kartenwert) alle den gleichen Wert aufzeigen. Es wird der höhere Wert als Einigungswert angenommen.

In den nachfolgenden Retrospektiven sollten die Teams unter anderem auch untersuchen, ob die gewählten Einigungsregeln für sie sinnvoll sind.

Wenn das Team keine Einigung erlangt hat, ist die UserStory erneut zu erklären. Die meisten Teams haben sich auf die Regel verständigt, dass diese Erläuterung von denjenigen Personen vorgenommen wird, die die geringste und die höchste Schätzung gegeben haben. Andere Teams sehen auch noch eine weitere Erläuterung des Product Owners vor.  Um Zeitschwierigkeiten aus dem Weg zu gehen, lassen noch andere Teams eine offene Diskussion zu, welche durch ein Stoppuhr-Signal nach einer oder zwei Minuten beendet wird.

In "Agile Estimating and Planning" von Mike Cohn [Amazon-Buchlink] sind 13 Karten je Kartenset vorgesehen: ?, 0, 1/2, 1, 2, 3, 5, 8, 20, 40, 100, ? sowie ∞. Die Abfolge der Werte orientiert sich an der Fibonacci-Folge.

Um den Beteiligten nicht das falsche Gefühl von Exaktheit zu geben, weichen die Zahlen am oberen Ende von der Fibonacci-Folge ab. An Stelle der "20" und "40" wären für die Fibonacci-Folge "21" und "34" korrekt.

Dabei vereinbaren die Teilnehmer die folgenden Regeln für das Pokern:

Keine UserStory kann mit dem Wert "100" bepokert werden. "100" ist die Aufforderung, die Story weiter zu zerlegen. Es ist durch das Team zu klären, wie mit dem Erscheinen der "100" genau zu verfahren ist.

In einigen Teams sorgt das Aufzeigen der "100" durch eine Person für ein Zurückstellen der UserStory bzw. für eine sofortige Zerlegung.

In anderen Teams müssen alle Team-Mitglieder über eine "100" das Zerlegen einfordern, damit dieses ausgeführt wird.

Mittels "?" teilt der Schätzer beziehungsweise die Schätzerin mit, dass er oder sie sich unsicher und nicht in der Lage ist, eine Schätzung abzugeben.

Dabei vereinbaren einige Teams, dass das Ziehen der "?"-Karte einer Enthaltung entspricht.

Andere Teams vereinbaren, dass das durch das Aufzeigen der "?"-Karte eine weitere Erklärungs- und Schätztrunde initiiert wird.

Die "∞"-Karte zeigt an, dass der Betreffende eine Pause wünscht. Das Aufzeigen löst sofort die Pause aus. In einigen Kartensets ist an Stelle ∞-Zeichens auch passend eine Kaffeetasse aufgedruckt.

Einige Teams reduzieren dieses Kartenset lediglich auf die Zahlenwerte: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 sowie ?!. Sie vereinbaren dann gemeinschaftlich, dass das Aufzeigen der "100" jeweils eine erneute Erklärungs- und Schätzrunde nach sich zieht. Es gilt weiterhin die Regel, dass der- beziehungsweise diejenige die Auswahl der "100" kurz begründet, so dass das Team sich gegebenfalls auf die Bearbeitung der UserStory einigen kann.

Andere Kartensets weisen die Werte 0, 1, 2, 3, 4, 5, 6, 7, 8 auf. Für einige Teams ist das lineare Abschätzen von Komplexitäten einfacher. Dies wird durch die vorgegebene Abfolge ermöglicht. 

Wiederum andere Teams greifen auf Doppelkopf-Kartensets zurück. Diese nutzen die Teams entweder in einer linearen Abfolge As, 2, 3, 4, 5, 6, 7, 8 und König genutzt werden (As steht dann für eine "1"). Oder sie nutzen die Kartenwerte eher im Sinne einer Fibonacci-Folge: As, 2, 3, 5, 8 und König. 

In jedem Fall bedeutet der König, dass die UserStory zurückgestellt und geteilt werden muss. 

Je weniger Kartenwerte im Pokerset vorhanden sind, desto gröber und holzschnittartiger fällt die Schätzung aus. Umgekehrt können viele Werte das Team dazu verführen, sich in der trügerischen Sicherheit einer exakten Schätzung zu wähnen.

Jedes Team sollte genau darauf achten, ob es gut und erfolgreich mit den gewählten Pokerregeln die Komplexitäten der anstehenden Aufgaben korrekt abschätzen kann.

Zeigt die Erfahrung, dass das Team sich häufiger verschätzt, ist die Ursache hierfür zu suchen. Sind die Pokerregeln eine mögliche Antwort -- oder verschärfen die Pokerregeln andere Ursachen, sollte das Team sich während der Retrospektiven auf eine andere Pokerform einigen. 

Viel Glück beim Pokern -- und beim Definieren der für das betreffende Team richtigen Regeln!

Planning Poker® is a registered trademark of Mountain Goat Software LLC.