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

• Alle User Stories liegen auf einzelnen Story Cards verdeckt vor
• Das Team ist komplett vertreten und auch der Product Owner ist anwesend

Regeln

• Jemand aus dem Team nimmt sich die oberste Story, liest sie laut vor und hängt sie an die Wand.
• Der nächste aus dem Team nimmt die nächste Story, liest sie laut vor und hängt sie ebenfalls an die Wand. Er hat drei Möglichkeiten:
  • Die Story ist (seiner Meinung nach) ähnlich komplex wie die Erste. Dann hängt er sie neben die bereits an der Wand hängende Story.
  • Die Story ist (seiner Meinung nach) weniger komplex als die bereits hängende, die neue Story wird über die bereits an der Wand hängende gehängt.
  • Die Story ist (seiner Meinung nach) komplexer als die bereits hängende, die neue Story wird unter die bereits an der Wand hängende gehängt.
• Ab der dritten Story Card gibt es die folgenden Optionen:
  • Ausspielen der obersten Story Card wie oben beschrieben
  • Umhängen einer bereits gespielten Karte, verbunden mit einer (kurzen!) Erklärung, ohne Diskussion
  • Aussetzen

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.

Dieser Artikel wurde von Sven Röpstorff (www.transment.com) verfasst. Sven Röpstorff ist zertifizierter Project Management Professional (PMP) mit über 14 Jahren Berufserfahrung in unterschiedlichen Rollen im Projektmanagement. Seit Jahren beschäftigt er sich mit Agilität und hat als Certified Scrum Master (CSM) und Certified Scrum Practitioner (CSP) bereits erfolgreich Unternehmen bei der Einführung und dem Einsatz von Scrum begleitet.