Mit Magic Estimation schätzen

Scrum backlog Item
Von Sebastian Schneider // 30.04.2018 // 1 Kommentare

​Mit Magic Estimation können Sie eine große Anzahl von Aufgaben in eine relative Reihenfolge bringen. Was sich zunächst nach wirklicher "Magie" anhört, nutzt beim genaueren Ansehen eine sehr einfache und rudimentär wirksame Prinzipien für eine Ordnung. ​

​Für wen eignet sich der Artikel?

​Der Artikel ist für Sie dann interessant, wenn Sie zu den folgenden Personengruppen gehören:

  • ​Agiler Coach
  • ​Scrum Master
  • ​Product Owner
  • ​Entwicklungsteam

​und ein Interesse an schnellem agilem Schätzen haben. Aber auch wenn Sie nur ein reines Interesse an der Thematik haben, können Sie sich so in Magic Estimation einlesen. Sie brauchen kein fachliches Wissen, der genannten Rollen (aber es hilft).

​Wann Sie Magic Estimation nutzen können

​Die folgenden Fragestellungen sind für Magic Estimation typisch - fragen Sie sich einmal, ob diese bei Ihnen auf zutreffen:

  • ​​Haben Sie ein größeres Backlog, dass Sie bislang noch nicht mit Story Points abgeschätzt haben? ​
  • ​Haben Sie viele neue Product Backlog Items, die Sie abschätzen müssen?
  • ​Sie müssen irgendwas einfach schnell und relativ schätzen?

​Magic Estimation macht es einfach, große Mengen an Product Backlog Items zu schätzen. Das ist gerade für Teams immer wieder nötig, die irgendwann mit Scrum beginnen, aber schon viele Einträge aus der vorherigen Zeit mitbringen und diese aber nicht im geschätzten Zustand vorliegen.

Magic Estimation

​Vorbereitung von Magic Estimation

​Fibonacci-Reihe

​Die gute (angepasste) Fibonacci-Reihe, die in Scrum Projekten häufig zum Einsatz kommt, wird auch für Magic Estimation verwendet. Für die Vorbereitung sollten Sie:

  • ​Ein Set an Planning Poker Karten bereitstellen
  • ​Die Fibonacci-Reihe auf Klebezettel oder Karteikarten vorbereiten

​Product Backlog Items auf Karten bringen

​Sie wollen alle Product Backlog Items (PBI) schätzen? Dann benötigen Sie auch alle PBI's auf Zetteln. ​Drucken Sie also Ihre ganzen PBI's aus oder schreiben Sie diese einfach auf die Zettel, wenn es nicht zu viele sind.

​Klarheit der Product Backlog Einträge

​Die Product Backlog Einträge sollten allen Personen inhaltlich verständlich sein. Wenn Sie diese Voraussetzung nicht haben, dann werden Sie zu deutlich mehr Gesprächsbedarf im Termin tendieren.

​Festlegen einer Referenzstory

​Magic Estimation setzt auf die relative Schätzung, genau wie Planning Poker auch. Es ist immer wichtig zu wissen, gegen was man was in ​Relation setzt. Wenn diese Basis nicht gegeben ist, dann versteht jeder etwas anderes und ist dann auch in den Schätzungen nicht in der Lage etwas in Relation zu setzen.

​Ablauf von Magic Estimation

​Um einen erfolgreichen Ablauf von Magic Estimation zu erreichen, bieten sich die folgenden Punkte als Checks an, die in der Regel zu einer erfolgreichen Schätzung führen.

​Es wird nicht gesprochen

​Bei Magic Estimation wird nicht gesprochen. Jedenfalls nicht, während des eigentlichen Aktes, diese Karten auszulegen. Das ist aus meiner Sicht sinnvoll, aber nur möglich, wenn klar ist, welche Bedeutung die einzelnen Einträge inhaltlich haben.

​Verteilen der Einträge

​Die Einträge aus dem Backlog werden zufällig und möglichst gleichmäßig an alle Beteiligten verteilt.

​Schätzen der Einträge

​Jeder Teilnehmer schaut sich seine Product Backlog Items an und schätzt diese in Relation zu den anderen. Dabei legt er seine Schätzung dann genau zu einem Zahlenwert. Es werden keine Zwischenwerte benutzt, es gelten bei Magic Estimation eben nur die aus der genannten Fibonacci-Reihe.

​Zu diesem Zeitpunkt erlaube ich noch kein umlegen der einzelnen Werte. Ich finde es immer wichtig, dass alle mit dem einen fertig sind, bevor einige schon mit der nächsten Aufgabe starten wollen.

​Verändern der ​Schätzungen

​Wenn alle Product Backlog Items gelegt worden sind, dann ist es an der Zeit, sich einmal alle Einträge anzusehen und zu überprüfen, ob man mit der Schätzung der anderen einverstanden ist.

​Das funktioniert in der Regel dann gut, wenn wie oben beschrieben, die Referenzstory klar und verständlich war. Hier darf jeder sich ein paar Minuten Zeit nehmen und in Ruhe die PBI's ansehen.

​Jetzt besteht die Möglichkeit für jeden Einzelnen die Schätzungen zu verändern

  • ​Wenn jemand der Meinung ist, dass eine Schätzung nicht zutrifft, dann kann er diese einfach umlegen und muss das auch nicht begründen. Dabei markiert er die Karte mit einem Strich oder Punkt.
  • ​Wenn eine Karte drei Punkte bekommen hat, dann wird diese aus der Schätzung genommen und muss separat diskutiert werden. Hier ist das Verständnis scheinbar noch überhaupt nicht klar.

​Das Ende von Magic Estimation

​Magic Estimation ist beendet, wenn ​sich keine Karten mehr bewegen und die Teilnehmer mit der Reihenfolge zufrieden sind.

​Sollten Sie jetzt noch Product Backlog Items haben, die nicht zugeordnet werden konnten und mit drei Strichen herausgenommen wurden, müssen Sie diese noch klären. Dabei beachten Sie bitte die folgenden Punkte:

  • ​Sie sollten ​unklare Karten sofort klären. Sprechen Sie offen die PBI's mit drei Strichen an. Durch eine genauere Schätzung (z.B. mit Planning Poker) oder oft nur eine kurze Diskussion, können Sie die PBI's dann doch einsortieren - konsolidiert mit allen.
  • ​​Wenn Unklarheiten bleiben. Wenn eine Karte auch nach Diskussion und ggf. Nachschätzen mit Planning Poker zu keinem Ergebnis kommt, dann müssen Sie die Karte durch den Product Owner klären lassen Scheinbar ​fehlen hier noch die Informationen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>