
Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Es wurde 2002 von James Grenning erstmalig beschrieben und später durch Mike Cohn’s Buch Agile Estimating and Planning sehr populär. Die Regeln sind sehr einfach und das Schätzen kann nach wenigen einführenden Worten starten. Die größte Schwierigkeit bei der Einführung liegt meines Erachtens darin, dem Team den Sinn einer Schätzung von relativer Komplexität anstelle von Aufwand in Arbeitsstunden zu vermitteln.
Wenn diese erste Hürde genommen ist, steht man vor der nächsten Herausforderung: Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument dient oft “Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man diese Diskussionen als Scrum Master nicht in den Griff bekommt, dauert die initiale Schätzung des Product Backlog viel länger als geplant (falls man überhaupt durchkommt und die weitere Schätzung nicht in die Estimation Meetings während der Sprints verschiebt).
Auf dem Scrum Gathering 2009 habe ich nun eine Methode kennengelernt, die sehr vielversprechend klingt und schnell gute Ergebnisse liefert: Das Team Estimation Game nach Steve Bockman.
Die Regeln für das Spiel sind simpel …
Setup
Regeln
Spielende
Das Spiel ist beendet, wenn keine Story Cards mehr auf dem Tisch liegen und alle Spieler aussetzen.
Man hat nun sehr schnell einen Überblick über die relative Komplexität des gesamten Backlogs, ohne dass man sich in Lösungsdiskussionen für einzelne Stories verlaufen hat. In der Regel wird man bei den Story Cards an der Wand eine Cluster-Bildung beobachten, die sich nach dem Ende des Spiels hervorragend auf die Fibonacci-Reihe des Planning Poker Games projizieren lässt. Sollten es mehr als neun Cluster sein (1, 2, 3, 5, 8, 13, 20, 40, 100), kann man gemeinsam mit dem Team überlegen, ob und wie man Cluster zusammenfasst, z.B. indem man die beiden “kleinsten” Cluster zu einem macht. Dabei sollte man immer im Blick behalten, dass es sich hier um eine grobe Schätzung handelt und nicht um die Vorhersage der Zukunft.
Erweiterung
Beim Durchdenken des Spiels ist mir noch die Idee gekommen, dass man bereits an Wand befindliche und dann umgehängte Karten während des Spiels mit einem farbigen Klebepunkt markieren könnte, um den ‘Tatbestand’ des Umhängens ggf. für spätere Diskussionen festzuhalten. Je mehr farbige Punkte eine Story Card am Ende hat, desto weiter gehen offensichtlich die Meinungen bzgl. deren Komplexität auseinander. Dies ist auch ein gutes Indiz für den Product Owner, dass die Story möglicherweise noch nicht gründlich genug durchdacht wurde.
Ich werde diese Schätzmethode in meinem nächsten Scrum-Projekt ausprobieren. Falls jemand schon vorher dazu kommt oder bereits Erfahrungen mit dem Team Estimation Game gemacht hat, würde ich mich über eine Diskussion über Pros und Cons sehr freuen.
Update 22.03.2010:
Ich habe das Team Estimation Game mit einem Team gespielt und bin beindruckt von der Effektivität. Meinen Erfahrungsbericht “Bye bye, Planning Poker?” habe ich als eigenen Artikel gepostet.
Copyright ® 2010 - PROJEKT-LOG
RSS Feed abonnieren
![]()

2 Kommentare zu Team Estimation Game
Tweets die Team Estimation Game | Projekt-log.de erwähnt -- Topsy.com
27.10.2009 um %H:%M
[...] Dieser Eintrag wurde auf Twitter von Robert Wiechmann und dominanz, Robert Wiechmann erwähnt. Robert Wiechmann sagte: Team Estimation Game http://url4.eu/fHBQ [...]
Die Struktur des Heiligen Grals | PROJEKT-LOG
20.05.2010 um %H:%M
[...] Komplexität des Backlog Items (vgl. Artikel “Team Estimation Game“), die vom Team geschätzte [...]