Kategorien
Planungspoker
Ich habe ja irgendwann mal groß rumgetönt, dass ich auch mal was zum Thema Projektmanagement zu schreiben. Bis jetzt kam ich leider noch nicht dazu. Aber das soll sich heute ändern, denn ich will mal ein paar Worte zum Thema Planungs Poker verlieren.
Ich hatte es ja schon mal erwähnt, dass wir bei uns im Team agil mit Scrum arbeiten. Leider hat es dieses Jahr, durch diverse Sparmaßnahmen, nicht gereicht eine Scrum Master Schulung zu machen. Aber ich schweife schon wieder ab. Hier und heute soll es um Planungs Poker gehen.
Worum geht es also beim Pokern? Stellen wir uns mal ein einfaches Szenario vor: wir sitzen im Meeting und müssen ein Feature im Team schätzen. Früher war es bei uns so, dass jeder kurz erläutert hat wie viele Stunden man brauchen könnte und warum. Und wenn wir eins von „Wer wird Millionär“ gelernt haben, außer vielleicht das Horst Schlämmer witzig sein kann, ist, dass man mit dem was man sagt, das Publikum beeinträchtigt. Die nächsten Sprecher werden also beeinflusst von den Aussagen der Vorredner sein. Wenn jemand ein Feature auf eine Stunde schätzt, dann wird sich der nächste nicht mehr trauen 2 Tage anzugeben.
Und genau hier kommt das Planung Poker ins Spiel. Jedes Teammitglied bekommt ein Kartenspiel in die Hand mit vorgegebenen Zahlen, die die Stunden repräsentieren, die er schätzt. Jeder legt also die Zahl verdeckt auf den Tisch und alle decken sie dann gemeinsam auf. Ihr werdet sehen, dass jetzt höhere Differenzen und somit auch ausführlichere Gespräche als Ergebnis rauskommen werden. Diskussion bedeutet in diesen Fall, dass man sich eher mit der Materie beschäftigt, genauer drüber nachdenkt und somit bessere Zahlen liefern kann.
Ein kleiner Trick, der in der Scrum Gemeinde relativ gängig ist, ist die Wahl der Zeiten, die man Schätzen kann. Nicht jede Stundenzahl kann genommen werden. Und da man davon ausgehen kann, dass die Schätzung, je größer das Feature ist, immer ungenauer werden, so sollten auch die Zahlen, die man zur Wahl hat, immer größere Differenzen aufzeigen. Hier bieten sich die Fibonacci Zahlen (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …) an. Berechnet werden sie einfach, indem man die zwei vorhergehenden Zahlen aufeinander addiert. Kann man für kleine Aufgaben noch relativ genau schätzen, so muss man nicht wild drauf los raten bei großen.
Nach meiner Erfahrung nimmt dies auch den Druck auf die Entwickler, die schätzen müssen. Denn die Angst, auf eine Schätzung vom Management festgenagelt zu werden besteht fast immer und wenn es einem der Prozess nicht möglich macht „genauer“ zu tippen, dann muss die Schuld am Prozess liegen. Aber mal Hand aufs Herz, ob ein Feature 60 oder 65 Stunden benötigt, weiß man oft erst, wenn man 59 Stunden daran gearbeitet hat.
Eine interessante Vorgehensweise. Werd ich mir merken, gerade das Thema Zeitschätzung ist immer wieder ein Problem.
Viele Grüße
Tobi
Wenn man Untersuchungen trauen kann, dann ist es ganz normal, das Erstschätzungen um 400% daneben liegen in der IT.
Moin Nils!
Auch ich spiele gerne Planning Poker. Es ist eine vergleichsweise einfache stressfreie Technik der Zeitschätzung. Allerdings verwende ich einige Abwandlungen.
Die erste Abwandlung ist minimal. Da praktisch alle MySQL-Entwickler von ihrem Home-Office aus arbeiten, ist es nicht möglich ein echtes Pokerspiel nachzuahmen. Es kommt selten vor, daß wir alle an einem Tisch sitzen. Deshalb werden die Zeitschätzungen per E-Mail eingereicht und über eine Wiki-Seite diskutiert. Dies leidet unter dem klassischen Nachteil jeder Online-Kommunikation: die Kommunikation ist ärmer, man kann nicht auf die Körpersprache oder Stimmlage der Teilnehmer achten, wenn die Karten „aufgedeckt“ werden.
Je nach Zusammensetzung der Pokerrunde wird in Stunden/Tagen oder in abstrakten Größen geschätzt.
Zu einem sehr frühen Zeitpunkt im Projekt bestehen meist noch viele Unklarheiten – Du deutest es selbst an. Deshalb bitte ich die Pokerspieler darum nur die relative Größe der Aufgaben zueinander zu schätzen. Eine Aufgabe des Umfangs 3 benötigt etwa die dreifache Menge an Zeit zur Lösung wie eine Aufgabe des Umfangs 1. Es ist im ersten Schritt keine Aussage darüber getroffen wie lange es dauert einen Wertungspunkt abzuarbeiten.
Bei einer heterogenen Projektgruppe hat dieser erste Durchlauf ohne konkrete Zeitangaben Vorteile. Ein Entwickler, welcher bereits Erfahrungen mit den Techniken gesammt hat, die zur Lösung der Aufgabe A notwendig sein, könnte schätzen, daß es einen Tag dauert die Aufgabe abzuarbeiten. Ein Einsteiger, der ebenfalls am Pokerspiel teilnimmt, könnte seine eigene Leistung völlig korrekt schwächer einschätzen und vier Tage veranschlagen. In dem Moment in dem beide Spieler ihre Karten aufdecken, wird sich der Einsteiger erschrecken. Sein Blatt ist viel „schwächer“. Er steht als langsamer Arbeiter da. Was mag das für sein Gehalt und seine berufliche Zukunft bedeuten, sollte der Einsteiger „bluffen“?
Falls in der ersten Runde nur die relative Größe der Aufgaben zueinander geschätzt wird, dann gibt es keinen Grund mehr für den Einsteiger zu „bluffen“. Beispiel: ein Experte schätzt eine Aufgabe auf den Umfang zwei und denkt im Stillen „drei Tage“. Der Einsteiger schätzt ebenfalls einen Umfang von zwei, weil die Aufgabe ungefähr doppelt so groß ist wie eine Vergleichsaufgabe. Allerdings fürchtet der Einsteiger eine Woche an der geschätzten Aufgabe zu arbeiten. Experte und Einsteiger schätzen bei auf den abstrakten Umfang von zwei. Ihre Zeitschätzung differiert jedoch um 40% – drei vs. fünf Tage.
Auch wenn eine Gruppe homogen besetzt ist und ein solides Vertrauensverhältnis besteht verbleibt ein Vorteil der abstrakten Schätzung. Die Teilnehmer schätzen nur die relative Größe von Aufgaben. Sie führen Vergleiche durch. Vergleiche geraten oft einfacher und genauer als echte Schätzungen.
Falls das Pokerspiel mit abstrakten Größen und Vergleichen begonnen wird, sind zwei Runden notwendig. In der zweiten Runde diskutiert die Gruppe wieviele Wertungspunkte sie pro Iteration abarbeiten möchte. Anhand von Soll-Ist-Vergleichen, Breakdown-Charts und Neuschätzungen ergibt sich bald ein brauchbares Bild des Projektstatus und des Projektfortschritts. Die anfängliche Schätzung wird dabei immer weiter präzisiert.
Natürlich kann es passieren, daß einzelne Aufgaben völlig falsch eingeschätzt wurden. Durch die regelmäßige Statusüberprüfung sollten diese unangenehmen Nachrichten jedoch früh erkennbar werden.
Ich genieße den Luxus nicht draußen an der Kundenfront zu sein. Ich muß keine verbindliche Kostenschätzung abliefern. Aber auch für Kostenschätzungen finden sich in der Literatur wertvolle Tipps, die andeuten wie aus einem abstrakten Planning Poker-Spiel ein Preisvorschlag wird.
Manchmal ist mir das Pokern aber auch zu aufwändig und wir rufen uns einfach ein paar Stunden oder Tage im IRC zu und schnauzen uns an, wenn es länger dauert…
Ulf
Hallo Ulf,
erstmal vielen Dank für deinen ausführlichen Kommentar. Wir hatten auch angefangen mit Storypoints zu schätzen, was deinen abstrakten Einheiten entspricht, dies aber nur auf Feauture und nicht auf Task Ebene. Es wurde aber leider nicht von den Entwicklern angenommen und deswegen sind wir wieder auf Stunden gewechselt. Das war bei uns auch kein Problem, da wir bereits eine lange Zeit zusammenarbeiten und wir alle vor Ort sind.
Unsere Stunden sind auch Idealstunden, was bedeutet, dass wir nicht 8 Std. am Tag abarbeiten können. Im Schnitt kommen wir pro Entwickler auf ca. 5 Std. am Tag reiner Entwicklungszeit, also Zeit, die wir von unserem Burndown Chart streichen können.
Gruß,
Nils
@All: Ich werde die nächste Zeit auch mal einen kleinen Bericht über die Scrum Artefakte und Meetings schreiben (mit Hilfe von Timo). Falls also jemand nicht weiß, was ein Burndown Chart ist, dann werden wir das bald ändern.
Jupp, ich nenne sie auch Story Points und es sind auch fast Story Points. Das wichtigste bei all diesen Techniken dürfte sein, die Grundidee zu verstehen und diese den jeweiligen Bedürfnissen anzupassen.
Super Beitrag!
Das sind denke ich so Sachen die man in keinem PM Buch finden wird.
Ich freu mich schon auf die nächsten Beiträge zum Thema PM.
Gruß,
Thomas
@Thomas
Das Buch zum Thema ist „Agile Estimations and Planning“, http://www.amazon.de/exec/obidos/ASIN/0131479415/phpdoc .
Dann hast du ja fast Glück, dass du noch kein ScrumMaster Training hattest, der Dozent hätte dir nämlich den Kopf abgerissen für das Schätzen in Stunden 😀
Das Problem warum es bei euch wahrscheinlich nicht geklappt hat, war, dass ihr euch nicht von konkreten Einheiten wie Zeit loslösen konntet. Dabei schätzt man bei Scrum nur Größen. Man legt vor dem Schätzen (in der Regel reicht das beim allerersten Estimation Meeting) ein Referenzitem fest, dem man die Größe 2 gibt (sollte also ein möglichst einfaches Item sein). Alle anderen Items werden nur noch in Relation zu diesem 2er-Item geschätzt. Man schätzt also Größen, nix anderes. Wichtig ist auch zu verstehen, dass nur Items/Features geschätzt werden, keine Tasks, erst recht keine technischen! Die haben ohnehin nix auf dem Product Backlog verloren, dieses besteht nämlich nur aus Features.
Der Nachteil in Stunden zu schätzen ist ganz klar: Abgesehen davon, dass du dann immer eine Person findest, die dich nach dieser Schätzung wertet („Du hast aber gesagt du brauchst nur 4 Stunden!“), hat es auch noch den von Ulf genannten Effekt. Ganz davon zu schweigen, dass sich Größen wie Velocity mit Stunden irgendwie nicht so wirklich vernünftig verwenden lassen: „Wir schaffen 170 Stunden in einem Monat!“.
Wenn man’s genauer nimmt (jetzt gehts tiefer in Scrum) sind die geschätzten Größen fast komplett irrelevant. Es zählt nämlich das was hinten rauskommt, also die abgearbeiteten Features! Was interessiert deinen Kunden, ob du nun 170 Storypoints oder Arbeitsstunden im Sprint verwendet hast? Die 20 Features, die du in der Zeit umgesetzt hast, interessieren ihn viel mehr!
Wer sich übrigens mal in Scrum einlesen möchte, dem kann ich diese beiden Bücher hier empfehlen:
http://www.amazon.de/Scrum-Produkte-zuverl%C3%A4ssig-schnell-entwickeln/dp/3446414959/ref=sr_1_1?ie=UTF8&s=books&qid=1233784041&sr=8-1
http://www.amazon.de/Agile-Project-Management-Microsoft-Professional/dp/073561993X/ref=sr_1_7?ie=UTF8&s=books-intl-de&qid=1233784054&sr=8-7
Letzteres beschäftigt sich eher damit wie Firmen Scrum bei sich eingesetzt haben. Ich habe das Buch als erstes gelesen (als ich noch wenig Ahnung hatte) und es hat mir extrem viel geholfen.
Yippii!!! Heute sind unsere Planning Poker-Karten angekommen 😉
Ja was ein Super Template wo bekomm ich das bitte schreib mir per email danke
Auch wenn eine Gruppe homogen besetzt ist und ein solides Vertrauensverhältnis besteht verbleibt ein Vorteil der abstrakten Schätzung. Die Teilnehmer schätzen nur die relative Größe von Aufgaben. Sie führen Vergleiche durch. Vergleiche geraten oft einfacher und genauer als echte Schätzungen und der blog ist sehr interessant