“Blinds please!” oder: Was Aufwandsschätzung mit Pokern zu tun hat

von Reto M. Kiefer am 5. Februar 2010

Lesetipps

Im Rahmen meiner kleinen Reihe über agile Softwareentwicklung und Scrum möchte ich heute auf eine Technik eingehen, die beim leidlichen Thema der Aufwandsschätzung eine Hilfestellung sein kann: Planning Poker. Wer eine kleine Einführung in Scrum für Entwickler sucht, dem sei mein erster Artikel in diesem Blog empfohlen. Die Einbettung in den Scrum-Kontext ist auch mit ein Grund, den vor etwa einem Jahr hier erschienenen Artikel zu aktualisieren und zu ergänzen.

Da Scrum nur ein Rahmenwerk ist, wie Projekte abgewickelt werden sollen, hält es sich bei der konkreten Implementierung zurück, solange die Eckpfeiler (Rollen, Regeln und Time-Boxen) eingehalten werden. So ist Planning Poker kein fester Bestandteil von Scrum, aber durchaus Best Practice.

Zu Beginn eines Sprints werden im “Planning Meeting 1″ die Features, die in der Iteration umgesetzt werden sollen, besprochen und geschätzt. Der Product Owner gibt mit seiner Priorisierung die Wichtigkeit der Features vor. Weiterhin Best Practice ist, die Features in Form von User Stories zu verpacken, weil diese für den Techniker wie den Product Owner gleichermaßen verständlich sind. Wie viele User Stories in ein Sprint gepackt werden, hängt von der Aufwandsschätzung ab und damit sind wir mitten im Planning Poker.

Planning Poker ist ein spielerisches und konsensorientiertes Verfahren, um auf eine realistische Schätzung des Entwicklungsaufwands eines Features oder einer User Story zu kommen. Man benötigt dazu ein Kartenspiel mit speziellem Kartenwerten. Jeder im Entwicklungsteam erhält einen Satz, der die Karten: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, “?” und “Pause” umfasst.

Customized Planning Poker Karten

Der Scrum Master moderiert das Planning Poker und man einigt sich zu Beginn auf eine einfache User Story (etwa: „Ermögliche dem Besucher eine einfache Kontaktaufnahme mit dem Webseitenbetreiber über ein entsprechendes Formular“), die den Wert 2 bekommt. Der Product Owner stellt daraufhin die konkrete User Story vor und beschreibt nochmals, was sie umfasst. Dabei ist wichtig, dass der Product Owner eine Wertung wie „leicht“, „aufwändig“ oder „schnell umzusetzen“ auf jeden Fall vermeidet, um eine Voreingenommenheit des Teams zu vermeiden.

Daraufhin schätzen die Spieler für sich den Aufwand der gegeben User Story relativ zu dem mit 2 bewerteten Feature und legen alle gleichzeitig die Karte mit dem geschätzten Aufwand offen. Die beiden Spieler, die den jeweils höchsten und niedrigsten Wert geschätzt haben, müssen den anderen nun erklären, wie sie zu der Entscheidung kommen und die Schätzung begründen. Daraufhin wird das Prozedere wiederholt, bis sich ein Konsens unter den Spielern bildet. Lässt sich auch nach mehreren Durchgängen kein Konsens finden, bekommt der Entwickler, der die User Story am ehesten umsetzen wird mehr Gewicht oder man greift zu einem der konservativen Werte, um auf Nummer sicher zu gehen.

Für was die Werte auf den Karten stehen, wird zuvor festgelegt. Das können konkrete Manntage sein, es können aber genauso gut abstrakte Story Points sein, die einfach den Aufwand in Sachen Komplexität beschreiben ohne dabei eine Aussage zum Zeitaufwand zu treffen. Was ein Story Point in tatsächlich zeitlichem Aufwand bedeutet, wird sich erst nach einigen Sprints zeigen können. Das abstrakte Verfahren hat den Vorteil, dass die Schätzung in Relation zur Komplexität eines anderen geschieht und nicht immer der Gedanke an eine konkrete Zeit im Vordergrund steht.

Hat das Scrum Team alle im Sprint zu entwickelnden User Stories nach diesem Verfahren geschätzt, geht es dann im “Planning Meeting 2″ darum, aus den gewählten User Stories konkrete Entwicklungstasks zu erstellen, die das so genannte Sprint Backlog darstellen. Als Faustregel gilt dabei, dass ein Task so klein wie möglich und in maximal einem Tag zu realisieren sein soll.

Das Planning Poker hat einige Vorteile gegenüber anderen Schätzverfahren und es passt hervorragend in ein Scrum-Projekt:

Es gibt keinen Projektleiter, der vorgibt, wie lange etwas zu dauern hat. Das Entwicklungsteam ist autonom in seiner Schätzung.
Es werden alle Entwickler gleichberechtigt befragt und die Entscheidung fällt im Konsens.
Mit dem Verfahren kann man sowohl konservative wie progressive Schätzer-Typen einfangen und an einen Tisch holen.
Die Wiederholung des Planning Poker zu Beginn eines jeden Sprints sorgt für eine Optimierung des Schätzens und damit einer Erhöhung der Zuverlässigkeit des Teams.
Der Scrum Master moderiert das Verfahren, weist auf die Verbesserungen zwischen den einzelnen Sprints hin und erhöht das Selbstvertrauen des Teams in die eigenen Fähigkeiten.

Teams, die Planning Poker noch nicht kennen, sollten es unbedingt einmal ausprobieren. Es lockert nicht nur das nervige Schätzen durch spielerische Elemente auf, sondern es löst tatsächlich Probleme. Planning Poker Karten gibt es bei spezialisierten Händlern zu kaufen oder man lässt sich sein Kartenspiel von entsprechenden Dienstleistern individuell drucken – etwa im firmeneigenen Erscheinungsbild.

Reto M. Kiefer

Ich bin nunmehr seit der ersten Version von PHP3 dabei und habe in den Jahren eine richtiggehende Hassliebe zu PHP entwickelt. Begeistert von den Entwicklungen der Sprache und der Frameworks ist sie zu ...

Zum Profil von Reto M. Kiefer

15 Kommentare »

Reto M. Kiefer » Planning Poker Karten
am 5. Februar 2010 um 07:41 Uhr

[...] Methoden aus dem Umfeld der Projektabwicklung mit Scrum erscheint von mir demnächst wieder bei PHP hates me. Kategorien: Agile & Scrum, Development Schlagworte: Agile, Projektmanagement, Scrum [...]
Nils Langner
am 5. Februar 2010 um 07:48 Uhr

@Reto: Danke für den Artikel. Als wir damals in der alten Firma Scrum eingeführt haben, war Planungs Poker das einzige, was auf anhieb funktioniert hat und auch den Teiilnehmern sofort Spaß gemacht hat. Würde es also auch jedem empfehlen, auch im nicht-agilen Zusammenhang.
Sven
am 5. Februar 2010 um 08:59 Uhr

Vielen Dank für diesen klasse Artikel.
Könntest du bitte noch ein paar Sätze über die Karten “Pause” und “?” verfassen?
Wie geht man damit um wenn jemand diese Karten auf den Tisch legt und was genau haben Sie zu bedeuten?
Ich mein es bringt ja nichts, wenn jemand immer das “?” auf den Tisch legt.
Macht es vll. sogar Sinn die “?”-Karte aus dem Satz zu nehmen oder nur eingeschränkt zu erlauben?
Ralph Meier
am 5. Februar 2010 um 09:18 Uhr

Müssen wir wohl auch unbedingt bei uns ausprobieren. Sieht sehr interessant aus.
Wie sieht es mit den Schätzungs-Einheiten aus? Ich nehme an, ab einer gewissen Grösse müsste man die Schätzung unterteilen? Gibt es da Regeln, ab welchem Wert man diese Unterteilung macht?
Reto M. Kiefer
am 5. Februar 2010 um 09:27 Uhr

@Sven / Sonderkarten:

Die “?”-Karte ist optional. Sie wird ausgelegt, wenn man sich absolut unsicher ist, was in der Wirklichkeit vermutlich seltener vorkommen wird. Man kann aber sagen, dass wenn zu viele ? oder zu viele 100er gespielt werden (was auch nur bedeutet, dass die Story zu unübersichtlich / groß ist, um sie zu schätzen), das sich Team mit dem Product Owner überlegen muss, ob die gegebene Story nicht in kleinere Stories aufgeteilt werden muss. Die Pausenkarte wird einfach gespielt, wenn einer eine Pause braucht.

Dabei gilt immer, dass es ein kooperatives und konsensorientiertes Verfahren ist. Sprich wenn einer nicht mitspielen will, kann das die Methode sprengen. Es wäre dann Aufgabe des Scrum Masters denjenigen einzufangen. Wenn das nichts hilft, muss man wohl überlegen, ob derjenige noch in ein Scrum-Team passt oder ob er nicht besser in einer anderen Form der Projektabwicklung integriert werden sollte, sprich in ein anderes Team versetzt wird.

Scrum und auch das Planning Poker leben vom Mitmachen und sich darauf Einlassen. Es ist wie im Spiel. Wenn einer ständig das Spiel verdirbt, macht es auch keinen Sinn auf Dauer mit ihm zu spielen…
Reto M. Kiefer
am 5. Februar 2010 um 09:40 Uhr

@Ralph / zu den Schätzungseinheiten:

Wenn Userstories zu komplex werden, muss man sie in kleinere Stories unterteilen. Wenn z.B. an der User Story “Der User soll sich am System anmelden können” implizit eine komplexe Rechteverwaltung hängt ist das ein Fall für eine Aufsplittung. Das ist eine Sache, die sich nicht in dem Sinne in Regeln gießen lässt, sondern die jedes Team für sich selber herausfinden muss.

Eine große Hilfe sind da die abstrakten Story Points. Die sagen zunächst gar nichts über einen Zeitaufwand aus, sondern nur etwas über die Komplexität. Die Komplexität einer Story wird mit einer anderen verglichen und so kommt man dann auf Schätzungen.

Der Haken an diesem Verfahren ist, wie im Artikel beschrieben, dass das Team dem Product Owner oder dem Kunden erst dann Angaben zur tatsächlichen Zeit machen kann, wenn es selbst ein Gespür dafür entwickelt hat, wie sich welche Komplexität in welchen Zeiten niederschlägt. Das bringt erst die Erfahrung von einer paar Sprints oder Iterationen mit sich.
Stephan Hochdoerfer
am 5. Februar 2010 um 10:02 Uhr

Inwiefern macht den 0 Aufwand Sinn? Ist nicht alles Aufwand, selbst Kleinigkeiten wie Texte austauschen, Farben ändern usw?
Sven
am 5. Februar 2010 um 10:12 Uhr

@Reto M. Kiefer
Vielen Dank! Jetzt ist auch das letzte Dunkel erhellt.
Ich werde mal schauen ob es sich bei uns durchführen lässt.
Julia
am 5. Februar 2010 um 12:44 Uhr

und wieder etwas Licht ins Dunkel…DANKE!
Julian
am 5. Februar 2010 um 14:56 Uhr

Guter Artikel.

An welcher Projekt / Aufgabengröße setzt ihr Planungspoker ein?

Ist ja sicher zeitraubend es für jede Kleinigkeit zu nutzen, da denke ich ist die Effizienz dann nicht mehr unbedingt gegeben. Hier wird auch eine wichtige Entscheidung liegen, wie ich schätze.

Stimmt ihr mehrere Aufgaben hintereinander ab? Also “mehrere Runden”`?
Julian
am 5. Februar 2010 um 14:57 Uhr

*Ab
(Eine edit-Funktion wäre hier noch nett!)
Stephan
am 5. Februar 2010 um 20:48 Uhr

Ein wirklich sehr interessanter Artikel! Danke Reto.
Welche Artikel folgen denn noch von dir zu diesem Thema? So als Appetizer

Die Antwort auf Julians Frage, ob man mehrere Runden hintereinander spielt, würde mich auch interessieren.

Darüber hinaus interessiert mich, ab welcher Teamgröße das Planning Poker Sinn macht? Gibt es hier Erfahrungswerte?

Welche Rolle spielt die (Entwicklungs-)Erfahrung der beteiligten Personen? Wird die Schätzung eines Neulings im Team genauso gewichtet wie die eines “etablierten” Teammitglieds?
Reto M. Kiefer
am 6. Februar 2010 um 11:25 Uhr

@Julian

Das kommt ganz drauf an, wie das Projekt aussieht – für jede Kleinigkeit macht es keinen Sinn. Auch wenn immer das gleiche gemacht wird (etwa eine Agentur, die standardisierte Produkte vertreibt) macht es auf Dauer keinen Sinn, weil klar ist, was anfällt.

Im Rahmen von Scrum findet eine Poker Session jeweils zu Beginn des Sprints / der Iteration statt. Sprich, alle zwei oder vier Wochen setzt man sich zusammen, schätzt, pokert und bestimmt dann, was in dem Sprint gemacht wird. Um jede User Story wird einzeln “gepokert”.

Wer Sorge hat, dass das ausufert, kann eine Eieruhr einsetzen und festlegen, dass die Schätzung einer User Story maximal X Minuten dauern darf. Bewegt man sich im Scrum Kontext, ist das ganze Planning Meeting 1, also das Meeting, in dem gepokert wird, ohne hin durch eine Time-Box begrenzt.

Aber auch bei kleineren Projekten kann es Sinn machen, auch ohne Scrum. Was mir persönlich an dem Verfahren gefällt, dass sowohl konservative Schätzer (wie beispielsweise ich) und die “jungen Wilden” in der Firma, die sehr progressiv schätzen, sich austauschen und _gemeinsam_ einen Konsens finden müssen. Jeder Beteiligte wird befragt und jede Stimme zählt gleich
Reto M. Kiefer
am 6. Februar 2010 um 11:40 Uhr

@Stephan

Welche Artikel es noch geben wird, muss ich zum einen mit Nils abstimmen und zum anderen einmal recherchieren, zu was schon geschrieben wurde, damit es keine Doppelungen gibt. Was mich an der Thematik interessiert ist etwa der Workflow in agilen Projekten, auch in Hinsicht auf die eingesetzten Tools – aber lass Dich einfach überraschen. Ich freue mich jedenfalls, dass auch die nicht ganz so Hardcore-PHP-Themen gerne gelesen werden!

Zum Thema Teamgröße und Sinn des Verfahrens. Ein Scrum-Team besteht idealerweise aus 7 Personen, plus minus 2. Planning Poker ohne Scrum-Kontext kann man – so denke ich – getrost ab vier Leuten einsetzen. Das Wichtige dabei ist nicht zu vergessen, dass das Pokern ja nur eine Methode ist, um Konsens zu erzielen – den kann man ggf. auch zu zweit ohne Pokern erreichen.

Die Erfahrung des Teams spielt eine sehr große Rolle. Wenn das Team noch unerfahren ist, sollte auf jeden Fall ein erfahrender Scrum Master das Team begleiten. Er leitet das Team an und und hilft ihm dabei, sich zu verbessern – er ist der, wie ich letzten Artikel schrieb der “Kümmerer”. Die Stimme eines jeden Entwicklers zählt übrigens gleich. Kommt etwa ein neuer Entwickler hinzu ändert sich ja die gesamte Teamkonstellation und man muss einen temporären “Rückfall” in der Präzision der Schätzung und der Produktivität berücksichtigen.

Es gibt Techniken, um die sog. Velocity eines Teams zu messen und grafisch darzustellen. Daran kann man gut ablesen, wie sich das Team von Sprint zu Sprint verbessert. Diese Auswertungen sind bei Scrum übrigens nicht nur für das Management gedacht sondern für alle ständig einsehbar. Da sich das Verhältnis von Schätzung zu Implementierung und der allgemeinen Produktivität in der Regel steigert, ist dies für alle wichtig zu sehen und eine zusätzliche Motivation. Auch Fehleinschätzungen werden so sichtbar und lassen sich für den nächsten Sprint leichter korrigieren.

Pendelt sich das alles langsam auf einem Niveau ein, kann man von einem erfahrenden Team sprechen. Dann ist es auch besser möglich von angesetzten Story Points auf tatsächliche Zeitwerte abzuleiten.
Reto M. Kiefer
am 6. Februar 2010 um 14:54 Uhr

@ Stephan Hochdoerfer

Die Null macht natürlich nur Sinn, wenn die Ziffern eine abstrakte Einheit wie Story Points darstellen. Null Aufwand für eine User Story in Zeit gibt es nicht, wohl aber in Sachen Komplexität.

Folgen wir dem Beispiel mit dem Kontaktformular, das den Story Point Wert 2 hat, könnte bspw. eine 0 Point Story sein: “Der User soll sich am System abmelden können.”Im minimalen Fall lässt sich diese Story in 3 Tasks runter brechen: Link zum Logout setzen, Session löschen, Redirect auf Startseite. Die Tasks kosten natürlich ein bisschen Zeit aber von der Komplexität zu einem Formular, mit Validierung und Datenverarbeitung fallen sie nicht wirklich ins Gewicht.

Mit Erfahrung des Teams lassen sich nach einigen Sprints auch tatsächliche Zeitaufwände für 0er Stories finden. Die 0er Story Point sind genauso berechtigt wie die 100er. Ist eine 0er Story so gering, dass sie fast keine darstellt, kann man überlegen, sie mit einer anderen geringen zusammenfassen.