Team Estimation Game

Zuerst einmal muss ich mit einer Entschuldigung anfangen. Und zwar wollte ich mal erzählen, warum es zur Zeit eher ruhig hier im Blog ist. Es ist ja nicht so, dass ich bloggen auf einmal doof finde oder mir phphatesme keinen Spaß mehr macht. Es fehlt einfach die Zeit. So einfach ist die Erklärung. Ein wenig mehr zu tun im Job und ein Kind, dass jetzt immer mehr mit Papa  machen will, machen sich einfach bemerkbar. Ich hoffe, dass es wieder besser wird, aber momentan bedeutet dies, dass es zwischen einem und zwei Artikel die bleibt. Wie immer gilt natürlich, dass Co-Autoren herzlich willkommen sind.

So, ich habe ja gerade geschrieben, dass es im Job gerade ein wenig mehr zu tun gibt, als sonst, was wohl auch daran liegt, dass ich neben dem Qualitätsmanagement nun auch die Scrum-Master-Rolle übernommen habe. Und wenn man in einer Rolle aufgeht, dann arbeitet man ja auch gerne mal ein wenig länger. Da wir aber gerade beim Thema sind, handelt der heute Artikel auch von Scrum und dem Schätzen von Stories.

Es ist schon eine Weile her, aber wir haben hier im Blog mal eine Möglichkeit vorgestellt, wie man möglichst gut im Team schätzen kann. Planungspoker war da unser Tipp und ist es auch immer noch. Für mich ist das Pokern die Lösung, die zu den besten Ergebnissen kommt. Nur leider hat es ein Problem: Es dauert ewig. Wenn wir gerade am Anfang eines Projektes auf Planungspoker setzen und sagen wir mal 100 Stories (was eher einem kleineren Projekt entspricht) haben, dann könnt ihr euch ja vorstellen, was es bedeutet bei jeder dieser Stories eine geheime Schätzung abzugeben und danach in Diskussion einen Konsens im Team zu finden. Nach meiner Erfahrung kann man die Teammitglieder nach zwei Stunden eh nicht mehr Schätzen lassen, weil es einfach viel zu langweilig und anstrengend wird.

Wir brauchen eine Lösung, die schnell ist und trotzdem gute Werte liefert. Hier kommt das Team Estimation Game ins Spiel. Erfunden wurde es von Steve Bockman und ist prinzipiell sehr einfach. Man fängt damit an, alle Stories auszudrucken und auf einen Stapel zu legen. Teilnehmer dieses Meetings sind übrigens Team und Product-Owner. Jetzt stellt das Team sich in Reihe und Glied auf und der erste in der Reihe nimmt sich eine STory vom Stapel. Liest sie laut vor und pinnt sie in die Mitte einer Wand (Whiteboard, Pinnwand, …). Der nächste, der an der Reihe ist macht genau das gleiche. Nimmt sich eine Karte, liest sie vor und pinnt sie, falls sie  aufwendiger ist, als die die vorherige über ddiese, wenn sie gleich aufwendig ist neben sie und bei weniger Aufwand unter sie. Ich glaube, die Idee wird jetzt schon klar. Am Ende hat man eine nach Aufwand sortierte Liste der Stories. Jetzt kann man unten anfangen und einen Story-Point vergeben, die nächste Reihe dann 2 und so weiter. Die Fibonacci-Zahlen bieten sich auch hier an.

Damit aber nicht immer nur eine Person den Aufwand schätzt, sondern das Team auch ein Wörtchen mitzureden hat, gibt es noch eine Sonderregel. jeder, der an der Reihe ist, kann statt eine Karte zu nehmen eine bereits geschätzte nehmen und sie umhängen. So können Fehlschätzungen korrigiert werden und die Diskussion, die man in Scrum so liebt wird auch wieder eröffnet. Wenn man will, kann man diese Karte dann markieren, um sich später darüber zu unterhalten.

Ihr könnt euch vorstellen, dass das System um einiges schneller funktioniert, als die herkömmliche Vorgehensweise. Nachteile hat diese Methodik aber leider auch. Es ist nur schwer möglich, wenn die ganzen Stories einmal geschätzt wurden, auf Planungspoker zurückzuwechseln, da man dort andere Referenzen benutzt. Des Weiteren muss man immer wenn man wieder neue Stories im Backlog schätzen will sich die Tafel anschauen und mindestens aus jeder “Reihe” eine Story lesen, um zu wissen, mit welcher man sie vergleichen könnte. Diese Aufwärmphase kostet leider Zeit.

Alles in allem ist das Team Estimation Game aber trotzdem zu empfehlen. Wir haben zumindest in der Vergangenheit gute Ergebnisse damit erzielt.