Im letzten Jahr habe ich in meinem Artikel “Team Estimation Game” ausführlich eine Alternative zum weit verbreiteten Planning Poker vorgestellt. Kürzlich hatte ich endlich die Gelegenheit, diese Schätzmethode in einem Projekt anzuwenden und ich muss sagen: Ich bin beeindruckt. Dies ist mein Erfahrungsbericht.

Die Ausgangssituation:
Ich bin als Agile Coach zu einem Projektteam gestoßen, das seit etwa einem Jahr ein Webportal für einen externen Kunden entwickelte. Der Kunde hatte sehr hohe Ansprüche hinsichtlich Funktionsumfang und kurzfristigem Going Live, so dass das Team unter dem Druck des ersten Releases nach anfänglichen agilen Gehversuchen wieder in einen Command-and-Control-Modus zurückgefallen ist. Da der Kunde nach wie vor einen enormen Releasedruck aufbaute, konnten wir nicht innehalten und das Projekt neu strukturieren, sondern mussten quasi on the fly Änderungen in Richtung einer agilen Arbeitsweise vornehmen. Dies führte dazu, dass wir zunächst einen Sprint mit ungeschätzten Backlog Items durchgeführt haben und uns gerade mitten im zweiten Sprint befanden (ebenfalls mit ungeschätzten Backlog Items), bevor wir das erste Estimation Meeting ansetzen konnten. Auf den ersten Blick klingt dies problematisch, weil wir natürlich keine Velocity berechnen konnten, aber wir haben diesen vermeintlichen Nachteil zu unserem Vorteil nutzen können.

Die Anwendung:
Das Estimation Meeting war für eine Stunde geplant. Es sollten 54 Backlog Items geschätzt werden, davon 9 bereits erledigte aus Sprint 1, 13 aktuell in Arbeit befindliche aus Sprint 2 und 32 noch nicht begonnene Backlog Items. Da es das erste Estimation Meeting für das Team war, haben wir die ersten Minuten genutzt, um den Nutzen des Meetings für alle Beteiligten darzustellen und die Regeln für das anschließende Team Estimation Game zu erläutern.

Die bereits erledigten bzw. im aktuellen Sprint befindlichen Backlog Items musste das Team natürlich nicht mehr “schätzen”, da es sich ja in der Umsetzung bzw. Planung bereits sehr detailliert mit ihnen auseinandergesetzt hatte. Daher habe ich zunächst darum gebeten, diese bereits bekannten Backlog Items nacheinander zueinander in Beziehung zu setzen und an die Wand zu kleben (Sprint 1: grün, Sprint 2: orange). Nachdem dieser Schritt erledigt war, hatten wir bereits ein sieben Zeilen hohes Raster an der Wand. Der nächste Schritt bestand darin, die neuen Backlog Items (blau) sukzessive in Beziehung zu den bereits an der Wand befindlichen zu setzen.

Während des Spiels ergab sich eine Situation, die ich seinerzeit in meinem Artikel nicht berücksichtigt habe: Bezüglich eines Backlog Items gab es dauerhaft auseinanderlaufende Meinungen hinsichtlich dessen Größe; es wurde immer wieder umgehängt, so dass davon auszugehen war, dass hier keine einheitliche Meinung im Team herrschte. Nach dem fünften Umhängen haben wir das Item aus dem Spiel genommen und die umhängenden Kollegen aufgefordert, sich nach dem Meeting auf eine gemeinsame Größe zu einigen. Zwei weitere Items waren selbst dem Product Owner nicht mehr klar, diese haben wir ebenfalls kurzerhand aus dem Spiel genommen.

Am Ende des Spiels hatten wir sieben Zeilen mit jeweils mehreren Karten. Beginnend bei 1 haben wir die Scrum-Fibonacci-Reihe auf das Raster angewandt und so Werte zwischen 1 und 20 für die Backlog Items erhalten (siehe Foto).

Als Reality Check haben wir die Story Points für Sprint 1 und Sprint 2 ausgerechnet: Es waren 107 und 123 Story Points, committed per Bauchgefühl und rückwirkend betrachtet absolut plausibel.

Alles in allem hat das Team die 54 Backlog Items in weniger als einer Stunde geschätzt, d.h. ungefähr eine Minute pro Backlog Item. In Estimation Meetings in früheren Projekten, in denen wir Planning Poker als Schätzmethode eingesetzt haben, habe ich die Schätzung einzelner Items manchmal nach 10 Minuten abbrechen müssen, weil sich das Team in technischen Detaildiskussionen verrannt hatte. Unter diesem Gesichtspunkt ist das Team Estimation Game also ein absoluter Volltreffer: Man bekommt in extrem kurzer Zeit einen guten, groben Überblick über das gesamte Product Backlog.

Aber ist Planning Poker damit endgültig gestorben? Ich denke nicht, denn wir benutzen Planning Poker nach wie vor, um während der Sprints neu hinzugekommene Backlog Items zu schätzen. Meist handelt es sich nur um einige wenige, so dass mit dem Team Estimation Game kaum ein echtes Spiel zustande käme und der Aufwand, die alten Karten wieder an die Wand zu kleben, unverhältnismäßig hoch ist. In diesem Fall greifen wir wieder zu den guten alten Pokerkarten und setzen die neuen Backlog Items mittels Planning Poker in Beziehung zu den bereits erledigten.

Fazit:
Das Team Estmation Game ist für die initiale Product Backlog Schätzung oder eine größere Menge zu schätzender Backlog Items die Methode meiner Wahl, weil man so eine große Menge Items in sehr kurzer Zeit schätzen lassen kann. Wenn bereits ein Grundstock an geschätzen Items besteht und die Anzahl der neu hinzugekommen Items überschaubar ist, greife ich gern wieder auf Planning Poker zurück.

Update 24.03.2010
Mein gelehriger Scrum-Master-Schüler hat mir heute gezeigt, dass es auch anders geht. Er hat einfach die bereits geschätzten Backlog Items auf zwei zusammengeklebten Flipchart-Sheets befestigt, damit der Aufwand für Auf- und Abbau minimiert wird. Nun spielt er auch in den kurzen Estmation Meetings innerhalb eines Sprints das Team Estimation Game mit dem Team. Chapeau!