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. 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.

Agile Toolbox
Scrum
Schätzen
Boris Gloger
July 26, 2017

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?