Facebook
Twitter
Google+
Kommentare
5
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

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.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

5 Comments

  1. wir benutzen zur zeit auch das pokern da wir nicht so viele stories zu schätzen haben.

    den hier vorgestellten ansatz halte ich aber für eine schöne abwechslung oder auch eine alternative bevor man x stunden pokert. (wie du ja geschrieben hast macht es schnell wenig sinn zu pokern wenn alle müde werden)

    was ich allerdings etwas gewundert hat ist das ihr SP nach aufwand schätzt. Ich bin erzogen worden das man komplexität von aufwand strikt trennt und der aufwand im planning 2 gesondert geschätzt wird. Aber ihr scheint ja eien feste beziehung zwischen SP und Aufwand zu haben.

    Oder hänge ich mich da einfach an zwei holen wörtern auf? Beste Grüße

    Reply
  2. Warum schätzt ihr am Anfang gleich so einen großen Berg an Stories? Verstehen würde ich, wenn am Anfang grobe Epics stehen (die man im Team Estimation Game erst mal grob sortieren kann um den PO zu unterstützen), die eigentliche Schätzung aber erst am Anfang des Sprints (und dann mit Planning Poker) auf Basis des priorisierten Backlogs erfolgt.

    Eventuell sollte man die Karten die nachträglich umgelegt werden bei jeder Änderung mit einem Strich markieren und bei 3 Strichen in die „zu diskutieren“ Spalte hängen.

    Reply
  3. Warum schätzt ihr gleich am Anfang so einen großen Berg an Stories? Fängt man nicht eigentlich mit groben Epics an und verfeinert dann je näher die Spitze des Backlogs ist? Euer Vorgehen macht nur Sinn, wenn sich die Anforderungen und Prioritäten so gut wie nicht mehr ändern, ansonsten musst du bei jeder größeren Änderung neu schätzen.

    Die Epics im Team Estimation Game grob abzuschätzen um den Product Owner zu unterstützen macht aus meiner Sicht Sinn, die Detailschätzung (inkl. Diskussion) kann man ja am Anfang des Sprints immer noch (mittels Planning Poker) machen.

    Reply
  4. „ein Kind, dass jetzt immer mehr mit Papa machen will […] Ich hoffe, dass es wieder besser wird“ – in was für einer Welt leben wir in der das schlecht ist!? Aber spätestens mit der Pubertät löst sich das ..

    Und bevor das jetzt jemand falsch interpretiert: Ich vermute sehr sehr stark, dass das anders gemeint war als die eben gemachte Interpretation 🙂

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen