Dynamic Magic Estimation – Funktionalität schätzen 3.0

Schätzen. Egal, ob Funktionalität oder Aufwand geschätzt wird, es ist ein ewiges Thema. Hinzu kommen die verschiedenen Nachteile verschiedener Methoden, wie zum Beispiel die recht leichte Beeinflussbarkeit beim Planning Poker oder die Dauer des Team Estimation Games.Ich präferiere das Verfahren „Magic Estimation“, das Boris Gloger entwickelt hat (basierend auf der Idee zu „Affinity Estimation“ von Lowell Lindstrom). In der Umsetzung hat sich bei einigen Teams jedoch herauskristallisiert, dass durch das Nichtkommentieren von Änderungen beim Umsortieren von User Storys das gemeinsame Verständnis der Funktionalität (oder den Aufwand) nicht vertieft wird und so oftmals im Nachhinein Unsicherheiten, manchmal auch angeregte Diskussionen entstehen.Diesem Umstand begegne ich durch das Hinzufügen der kurzen Erklärung beim Umsortieren einer User Story beim Team Estimation Game zur Magic Estimation. Als alternative Variante kann man auch die bei Magic Estimation üblicherweise vorhandene Skala weglassen.Dynamic Magic Estimation läuft dann gemäß dem Ablauf der Magic Estimation, wie er von Boris Gloger in seinem Buch „Wie schätzt man in agilen Projekten“ dargestellt (und von dort zitiert) wird, so ab:

1. 1. Der Product Owner bereitet die User Storys vor.
      1. Geeignet sind Ausdrucke in DIN A4, mit Versalien
      2. Nummerierung nach aktueller Priorisierung nicht vergessen!
   2. Der ScrumMaster hat die Skala vorbereitet, falls nicht wie im Team Estimation Game darauf verzichtet werdensoll.
   3. Der Product Owner verteilt die User Storys möglichst gleichmäßig ans Team aus.
      1. Diese wichtige Regel bleibt erhalten: Ab hier wird die Estimation schweigend gespielt, auch nonverbaleKommunikation sollte nicht stattfinden.
   4. Die Teammitglieder lesen ihre User Storys und legen sie auf der Skala zu jener Zahl, die nach Meinung desjeweiligen Teammitglieds die Größe der User Story darstellt.
      1. Sollte ohne Skala gespielt werden, beginnt ein Teammitglied seine User Storys abzulegen. Hat dasTeammitglied alle seine User Storys abgelegt, ist das nächste Teammitglied dran.Hierbei gilt die Regel aus dem Team Estimation Game:Eine User Story ablegen, die nächste wird der Einschätzung nach darüber oder darunter abgelegt. Darüberbedeutet „kleiner“, darunter „größer“.
   5. Nun liest jedes Teammitglied noch die zuletzt einsortierten User Storys
   6. Jedes Teammitglied kann nun vortreten und eine User Story „verschieben“.
      1. Tritt ein Teammitglied nach vorne, hat es den „Vortritt“, auch wenn alle parallel das Verschiebendurchführen.
      2. Während des Umsortierens einer User Story gibt das Teammitglied eine kurze (!), diskussionsloseErklärung ab.
   7. Der Product Owner beobachtet die User Storys in dieser Phase sehr intensiv, da er herausfinden muss, ob eineoder mehrere User Storys „springen“. Diese markiert er mit einem Punkt oder einem sonstigen Merkmal, da hierweitere Klärung nötig ist.
      1. Der ScrumMaster notiert die Erklärungen.Diese können später noch sehr hilfreich sein, zum Beispiel bei markierten User Storys oder auch imSprint bei der Implementierung.
   8. Das Spiel ist beendet, wenn keine User Storys mehr umsortiert werden oder sich das Team sichtlich langweilt.

Dieses Verfahren beinhaltet alle Vorteile der Magic Estimation, angereichert durch die Erklärungen zum Verständnis einzelner Teammitglieder zu den User Storys. Auch der große Vorteil, dass jede User Story zur Referenz der anderen User Storys wird, bleibt erhalten.Autor: Karsten Klopmann, KI Solutions UG

Produkte schnell und effektiv, mit gesundem Menschenverstand, zu entwickeln ist für mich schon jeher ein Anliegen. Scrum hat mir dazu schon sehr bald den passenden Rahmen geboten. Seit 1999 selbständig, bin ich seit ca. 15 Jahren als ScrumMaster, Product Owner oder Business Analyst auch in skalierten Projekten bis ca. 160 Kolleginnen/Kollegen tätig und es bereitet mir jedes Mal Freude zu sehen wie sich die Teams weiterentwickeln.