Estimation – Bewahre die Magie

Auf der AgileEE 2011 Conference in Kiew hatte ich das Vergnügen, einen Workshop über Schätzmethoden auszurichten. Die Teilnehmer waren begeistert, da der größte Teil bisher nur Planning Poker kannte und es trotz aller Einschränkungen benutzte. Wir haben Planning Poker mit dem Team Estimation Game verglichen, das ich hier im Blog bereits vor einiger Zeit beschrieben habe (weitere Links unten) und außerdem mit Magic Estimation. Während das Team Estimation Game in letzter Zeit mehr und mehr Anhänger gefunden und Variationen wie Silent Grouping entwickelt hat, ist Magic Estimation noch nicht so bekannt.

Ich werde in diesem Beitrag Magic Estimation erklären, so dass Ihr Eurem Schätzungsportfolio eine weitere Methode hinzufügen könnt.

Die ursprüngliche Idee für Magic Estimation stammt von Lowell Lindstrom, der 2008 “Affinity Estimation” vorgeschlagen hat. Boris Gloger hat Lowell’s Idee aufgegriffen und zu Magic Estimation weiterentwickelt.Verglichen mit Planning Poker bekommt man mit Magic Estimation ein sehr gutes Schätzergebis in kurzer Zeit.

Vorbereitungen

Alle User Stories müssen auf einzelnen Karten vorliegen. Man benötigt einen Tisch, der idealerweise von allen Seiten zugänglich ist. Auf dem Tisch werden Karten mit T-Shirt-Größen ausgelegt (XS, S, M, L, XL, XXL, jeweils eine). Anschließend versammelt sich das ganze Team um den Tisch und die User Stories werden zufällig und gleichmäßig unter den Teilnehmern aufgeteilt..

Durchführung

Erste Runde

Wichtig: Diese Runde ist eine stille Runde! Es gibt keine Diskussionen!
Alle Teilnehmer schätzen gleichzeitig. Sie lesen die ihnen zugeteilten User Stories und ordnen sie den T-Shirt-Karten zu. Der Product Owner ist verfügbar und darf zu inhaltlichen Themen befragt werden, falls notwendig.

Sobald die ersten Karten auf dem Tisch liegen, entwickelt sich implizit eine Art Skala und die Teilnehmer können sich an den bereits auf dem Tisch liegenden Stories orientieren.

Die Runde ist vorbei, wenn alle User Stories auf dem Tisch liegen. Abhängig von der Anzahl der zu schätzenden Stories dauert dies in der Regel nicht länger als ein paar Minuten.

Zweite Runde

Das gesamte Team verteilt sich um den Tisch herum und betrachtet das Ergebnis. Falls jemand eine Karte einer anderen T-Shirt-Größe zuordnen möchte, darf er das tun, muss aber dem Team kurz erklären, warum er dieser Meinung ist. Auch in dieser Runde kann der Product Owner um Erläuterung gebeten werden. Sollte sich das Team bezüglich einer Karte nicht einigen können, wird sie zwecks späterer Klärung aus der Schätzung genommen.

Die zweite Runde ist vorbei, sobald niemand mehr eine Karte verschieben möchte.

Im letzten Schritt werden die T-Shirt-Größen mit der Scrum-Fibonacci-Sequenz ersetzt.

  • XS – 1
  • S – 2
  • M – 3
  • L – 5
  • XL- 8
  • XXL – 13

Boris Gloger benutzt die Fibonacci-Sequenz von Beginn an. Ich verzichte darauf, weil ich möchte, dass das Team sich komplett vom Denken in Zahlen löst. Zahlen werden unbewusst immer wieder miteinander, mit Tagen, Stunden oder Sonstigem verglichen. Ich möchte, dass sich das Team auf “größer, gleich, kleiner” konzentriert und die Stories nur relativ zueinander schätzt. Meiner Erfahrung nach reichen Einschätzungen bis 13 Story Points völlig aus, daher die Einschränkung auf sechs Kategorien. Alles was darüber liegt, ist in der Regel zu groß, um es sinnvoll zu schätzen oder in einem Sprint daran zu arbeiten.

Vorteile

Wie auch mit dem Team Estimation Game bekommt man mit Magic Estimation sehr schnell ein gutes Ergebnis, da die initiale Schäzung einer Story nicht ausdiskutiert wird, sondern von einer einzelnen Person vorgenommen wird. Die möglicherweise abweichenden Perspektiven der anderen Teilnehmer bekommt man in der zweiten Runde.

Verglichen mit dem (ohnehin schon schnellen) Team Estimation Game ist Magic Estimation noch einmal eine Spur schneller, da man nun nicht mehr sequentiell, sondern parallel schätzt..

Nachteile

Manchmal höre ich, dass das die “Weisheit der Vielen” (wisdom of crowds) mit dieser Methode verlorengeht. Das sehe ich nicht so, denn in der zweiten Runde bespricht das gesamte Team das Ergebnis und nimmt Anpassungen vor. Die Weisheit der Vielen geht also nicht verloren, sondern wird erst später im Prozess genutzt.

Erfahrungen

Während ich mit Planning Poker manchmal nach 10 Minuten die Schätzung abbrechen musste, weil sich keine Einigung abzeichnete, beträgt die durschschnittliche Schätzzeit pro User Story mit Magic Estimation etwa 30 Sekunden. Stellt Euch die Schätzung eines 100 Stories starken Product Backlogs mit Planning Poker vor. Bekommt man da nicht Alpträume? Mit Magic Estimation hat man innerhalb einer Stunde ein brauchbares Ergebnis vorliegen, das dem Planning-Poker-Ergebnis in nichts nachsteht.

Für unerfahrene Teams oder Teams, die sich mit dem Produkt noch nicht auskennen, würde ich eher das Team Estimation Game einsetzen als Magic Estimation. Durch die Parallelisierung ist man zwar enorm schnell, aber die sequentuelle Schätzung beim Team Estimation Game bietet eine Menge Information und Einblicke, die für unerfahrene Teams wichtig sein können, da jede Story und ihre Schätzung kurz besprochen wird.

Weiterführende Links

Autor: Sven Röpstorff

Sven Röpstorff arbeitet freiberuflich als agiler Projektmanager und Coach mit über 16 Jahren Berufserfahrung. Mit seinen Teams probiert er gern neue Wege und Methoden, um sich und sein Umfeld stets weiter zu verbessern. In seinen Vorträgen und Workshops bringt er den Menschen agile Vorgehensweisen auf interessante und spielerische Weise nahe und macht sie somit sichtbar, fühlbar, erlebbar.

2 Kommentare

  1. Pingback: Jahresrückblick 2011 plus Gewinnchance | PROJEKT-LOG

  2. Hi Sven,
    super Artikel, wir verwenden übrigens seit 2010 bereits Tiere, oder andere Symbole für die Fibonaci Sequenz. Du hast mit deinem Hinweis, die Zahlen verwirren vollkommen Recht.
    lg
    Boris