Effizient schätzen mit dem Team Estimation Game

Ausgangssituation

Das Team und sein Umfeld ist insgesamt unzufrieden mit dem Umstand, dass es im Product Backlog zwar viele Einträge gibt, nur wenige davon aber konkret abgeschätzt sind. Das Team hantelt sich mit seinen Schätzungen von Sprint zu Sprint, eine längerfristige Voraussagbarkeit fehlt.

Das Team schätzt im Grooming kaum relativ, sondern entwirft im Geiste die einzelnen Tasks zu einer Story und gibt dann eine Schätzung ab. Durch diese intensive Auseinandersetzung mit dem „Wie“ dauern die Groomings lange, und nur wenige Storys werden abgeschätzt.

Nun soll konkret der Umfang eines neuen Teilauftrags im Projekt rasch abgeschätzt werden, der Product Owner hat dazu zwölf User Storys vorbereitet.

Team Estimation Game

Ich habe vom Team Estimation Game das erste Mal aus dem Buch Scrum in der Praxis von Sven Röpstorff und Robert Wiechmann erfahren, und mittlerweile schon ein paar Mal mit sehr gutem Erfolg eingesetzt. Ursprünglich stammt die Idee laut Sven Röpstorff von Steve Bockman.

Hier kurz zusammengefasst die Regeln:

• Das Team gruppiert sich um einen Tisch oder um ein Whiteboard (ich favorisiere das Whiteboard, wobei alle Teammitglieder um das Whiteboard stehen; meiner Erfahrung nach führt das zu einem agileren Ablauf des Spiels).
• Die zu schätzenden User Storys werden auf Kärtchen geschrieben oder gedruckt und verdeckt oder offen auf einen Stapel gelegt (ich kann an Hand meiner Erfahrung noch keine gravierenden Vor- und Nachteile zu Gunsten des verdeckten oder offenen Spiels erkennen).
• Spielberechtigt sind alle Teammitglieder mit Ausnahme des Product Owners und des ScrumMasters.
• Das erste Teammitglied zieht eine User Story aus dem Stapel und positioniert sie in der Mitte des Whiteboards.
• Das zweite Teammitglied zieht eine weitere User Story und hat nun drei Möglichkeiten, diese in Relation zur ersten User Story auf dem Whiteboard zu positionieren:
  • Schätzt es die Komplexität der User Story ähnlich ein, positioniert es die User Story neben der ersten User Story.
  • Schätzt es die Komplexität der User Story geringer ein, positioniert es die User Story über der ersten User Story.
  • Schätzt es die Komplexität der User Story größer ein, positioniert es die User Story unter der ersten User Story.
• Das dritte Teammitglied hat nun zwei Möglichkeiten für den nächsten Spielzug:
  • Es zieht eine weitere User Story und positioniert sie wie das zweite Teammitglied auf dem Whiteboard; oder
  • es verändert die Position einer bereits platzierten User Story auf dem Whiteboard, weil es mit der bisherigen Relation der Komplexitäten nicht einverstanden ist.
• Nun setzen der Reihe nach die weiteren Teammitglieder fort. Ein Teammitglied kann auch pausieren, d.h. keinen Spielzug durchführen. Nachdem alle Teammitglieder an der Reihe waren, setzt wieder das erste Teammitglied fort.
• Das Spiel ist zu Ende, wenn alle User Storys vom Stapel ausgespielt worden sind, und kein Teammitglied mehr die Position einer User Story verändern möchte.
• Um festzuhalten, ob im Team die Einschätzungen für die Komplexität einer User Story stark divergieren, kann je Neupositionierung einer User Story am Whiteboard das entsprechende Kärtchen mit einem Klebepunkt markiert werden. Weiters kann man auch ein maximales Limit an möglichen Klebepunkten festlegen. Bei Erreichen dieses Limits darf die User Story dann nicht mehr weiter repositioniert werden. So wird schnell klar, dass es für diese User Story weiteren Diskussionsbedarf gibt, das Spiel wird aber nicht unnötig in die Länge gezogen.

Der Ablauf in diesem Fall

Ich habe den Ablauf auf die konkrete Situation angepasst und um zwei Elemente ergänzt.

Da das Team bisher die zu schätzenden User Storys noch nie gegroomt hat, beginnt der Product Owner mit einer kurzen Vorstellung des Ziels des Teilauftrags sowie der zwölf vorbereiteten User Storys (meine erste Erweiterung). Das geht sehr effizient über die Bühne und dauert inklusive Verständnisfragen aus dem Team 20 Minuten.

Anschließend spielt das Team mit den auf Kärtchen aufgedruckten User Storys das Team Estimation Game. Zunächst noch etwas zögerlich, im Verlauf des Spiels aber zunehmend spielfreudiger, bringen die Teammitglieder neue Storys ins Spiel bzw. verändern die Anordnung der Storys zueinander und damit die Einschätzung der Komplexität. Nach etwa 30 Minuten hat das Team eine Anordnung der User Storys gefunden, mit der alle zufrieden sind. Die User Storys sind nun in insgesamt fünf Zeilen angeordnet, mit einem Schwergewicht der User Storys in den Zeilen 3 und 4.

Nur eine User Story bekommt im Laufe des Spiels drei Klebepunkte (unser festgelegtes Limit), mit dem dritten Klebepunkt hat aber auch diese User Story einen Platz in der Anordnung gefunden, mit der das Team zufrieden ist.

Abschließend bitte ich nun das Team, den Zeilen der Anordnung konkrete Storypoint-Werte zuzuordnen, um einen Bezug zur bisherigen „Eichung“ der Komplexitätsbewertung des Teams herzustellen (meine zweite Anpassung). Ich biete dem Team dazu die Kärtchen aus dem Planning Poker Set mit den Werten 1, 2, 3, 5, 8, 13 und 20 an. Das Team verständigt sich recht schnell darauf, den 5 Zeilen die Werte 2, 3, 5, 8 und 13 zuzuordnen. Dabei tauscht das Team noch drei User Storys zwischen den Zeilen 3 (5 Storypoints) und 4 (8 Storypoints) hin und her.

Nach nun insgesamt 60 Minuten Zeit hat das Team alle Storys konkret geschätzt.

Resümee

Ich bin mit dem Ablauf und dem Ergebnis der Schätzung sehr zufrieden.

Im Gegensatz zu anderen Groomings des Teams verzettelte sich das Team nicht in technischen Detaildiskussionen und unternahm nicht den Versuch, im Geiste die notwendigen Tätigkeiten für die Umsetzung der User Story durchzugehen, um erst anschließend daran zu schätzen. Stattdessen konzentrierten sich alle Teammitglieder auf die Einschätzung der Komplexität relativ zueinander.

Aus dem Team kam in einem abschließenden Blitzlicht sehr positives Feedback zum Team Estimation Game, die Leute waren einerseits sehr überrascht über die hohe Effizienz des Vorgehens und zeigten sich andererseits sehr zufrieden mit der Qualität der durchgeführten Schätzung (eine Rückmeldung im O-Ton: „Ich glaube nicht, dass eine Schätzung mittels unseres herkömmlichen Weges höhere Qualität gebracht hätte“).