Kategorien
„Blinds please!“ oder: Was Aufwandsschätzung mit Pokern zu tun hat
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.
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: 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.
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?
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?
@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…
@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.
Inwiefern macht den 0 Aufwand Sinn? Ist nicht alles Aufwand, selbst Kleinigkeiten wie Texte austauschen, Farben ändern usw?
@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.
und wieder etwas Licht ins Dunkel…DANKE!
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“`?
*Ab
(Eine edit-Funktion wäre hier noch nett!)
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?
@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
@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.
@ 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.
Guter Artikel! So wie hier beschrieben, setzen wir auch gerade ein agiles Projekt um. Kann dem Autor nur zustimmen!
Ein schöner Artikel und eine witzige Idee. Vorallem merkt man dann schnell, wenn man über Features spricht, was an der Spezifikation noch fehlt. Der denkt halt bei „xyz“ direkt an die Eierlegende-Wollmilch-Sau und der andere hatte einfach vor einen Button zu benutzen.
Das Einzige was etwas schade ist:
Es gibt keine einzige Pokervariante, die auf dieser Spiel-Basis funktioniert 🙂