Emendare
  • Agile Unternehmensberatung
  • Agiles Arbeiten
    • Was ist Scrum?
    • Was macht ein Product Owner?
    • Was macht ein Scrum Master?
    • Agile Führung – Was macht eine Agile Führungskraft?
    • Dialogische Unternehmenskultur
  • Methode
  • Prinzipien
  • Akademie
    • CSM Scrum Master
    • A-CSM Advanced Scrum Master
    • CSP-SM Scrum Professional – Scrum Master
    • Agiles Produkt Management – Grundlagen (CSPO)
    • Agiles Produkt Management – Advanced
    • Agiles Produkt Management – Masterclass
    • Agile Führung – Grundlagen
    • Agile Führung – Advanced
  • Team
  • Suche
  • Menü Menü

Magic Estimation – Die Grundlagen

In diesem Artikel zeige ich Euch 4 Varianten vom Methodenklassiker  „Magic Estimation“. Eine kurze und einfache Moderationsmethode, die, je nach Zielsetzung, für viel Interaktion, schnelle Information oder greifbare Visualisierung sorgen wird.

Das Ziel von Magic estimation in der Urversion ist es, schnell einen Schätzwert für die Komplexität eines gesamten Backlogs zu erhalten. Um das ganz deutlich zu machen. Das gewünschte Artefakt ist ein SCHÄTZ-Wert. Es gibt also kein falsch und richtig.

Typischerweise haben sich Product Owner, die Kunden und die Entwickler beim Start eines neuen Produktes, zum Start einer neuen Release Version oder einfach für die Prognose der kommenden Features ein Backlog gebaut. Hierbei ist es absolut sinnvoll direkt mit der MoSCoW-Methode zu arbeiten. Das Backlog hat sich mit tollen Ideen gefüllt und ist nun ca. 100 Backlogitems lang.

Hier braucht es jetzt eine schnelle interaktive Methode um in 10 Minuten eine ungefähre Schätzung für die Komplexität der Items durchzuführen. Geht nicht?

Oh doch.

Alles was das Team braucht sind mit den BacklogItems beschriebene Post-Its (gerne auch digitale Post-Ist auf dem Tool Eurer Wahl) und eine freie Wand. Die ProductOwner tun gut daran, sich auf viele Notizen vorzubereiten. Der Moderator kann abhängig von der Reife des Teams die bekannte Fibonacci Zahlenreihe als Überschriften vorbereiten. Reife Teams können auch ohne starten und dann im Nachgang die Zahlen den Gruppen zuordnen.

Mentos moderiert MagicEstimation beim Kunden.

Der Moderator verliest die Fragestellung nach der gruppiert/sortiert werden soll. In unserem Beispiel die Frage „Welche Backlogitems sind wie komplex?”

Jetzt folgt das Entwicklungsteam (und je nach Kontext dürfen das auch andere Kollegen sein) folgenden einfachen Regeln (hier erst mal in der leisen Variante):

  1. Du darfst nicht sprechen.
  2. Du darfst entweder ein BacklogItem vom Stapel nehmen und an der Wand einsortieren oder ein Backlogitem an der Wand umsortieren oder passen.
  3. Jedes Backlogitem, das umsortiert wird, erhält einen kleinen Punkt.

Der erste Entwickler wird ein Backlogitem vom Stapel nehmen und mitten an der Wand anbringen, vielleicht unter der „5″
Der zweite Entwickler nimmt ebenfalls ein BacklogItem und hängt es links oder rechts daneben unter die „3!.
Der dritte Entwickler nimmt, die Karte unter der „3″ und hängt sie unter die „13″. Der Moderator macht einen Punkt auf die Karte.

Der Product Owner ist aufmerksam welche Karten oft umgehängt werden oder achtet darauf, dass alle verschobenen Items einen Punkt erhalten. Hierzu gibt es definitiv noch Klärungsbedarf. Dieses Vorgehen wird wiederholt bis der Stapel leer, die Wand voll und alle zufrieden sind. Als Team erhalte ich so wahnsinnig schnell (100 Backlogitems in 20-30 Minuten) eine erste Einschätzung zur Gesamtkomplexität und das Team kann bereits die Backlogitems identifizieren, die noch zu groß oder unklar zur Schätzung sind.

Magic Estimation – die Dialogvariante

Die erste Regel in der grundliegenden Methode ist „Du darfst nicht sprechen!“. Das beschleunigt den Prozess und schärft den Fokus der Teilnehmer. Sollte mein Ziel allerdings sein mit etwas mehr Zeit in einen tieferen Lern- und Beratungsprozess einzutauchen, empfehle ich genau diese eine Regel ausser Kraft zu setzen. Alles andere bleibt gleich.
Der erste Entwickler wird also ein Backlogitem vom Stapel nehmen und mitten an der Wand anbringen, vielleicht unter der „5″
Der zweite Entwickler nimmt ebenfalls ein BacklogItem und hängt es links daneben unter die „3!.
Der dritte Entwickler nimmt, die Karte unter der „3″ und hängt sie unter die „13″. Er muss diese Veränderung begründen. Beispielsweise: „Dazu benötigen wir ein Update unserer Datenbank!”
Der vierte Entwickler nimmt diese Karte erneut und schiebt sie mit den Worten „der Prozess ist komplett automatisiert, es verbleibt nur die Datenbank” zurück unter die „3″
Hier lernen jetzt alle Beteiligten viel über die anstehenden Aufgaben und Abhängigkeiten zwischen den Backlogitems. Die Methode wird langsamer und erzeugt gemeinsames Lernen an der Produktidee oder der Umsetzung. Hierbei ist ein Moderator gefragt, um Ping-Pong von einzelnen Tickets und all zu abschweifende Dialoge in konstruktive Bahnen zu lenken. Product Owner sollten sich Rückfragen, Abhängigkeiten und Fragen notieren und damit den Refinementprozess vorantreiben. Ich erlebe es sehr oft, dass diese Art der Backlogschätzung zu viel Begeisterung, Vorfreude und einem „Ja, wir schaffen das! (Bob der Baumeister)” führt.

Magic Estimation – weitere Einsatzfelder

Mit dieser Dialogvariante kann ich auch weitere Fragestellungen verfolgen:
  • Welchen relativen Wert hat denn welches Backlogitem? Es bietet sich an nicht nur die Komplexität sondern auch den Wert einer Story zu schätzen. Hier können Product Owner, Produktdesigner, Kunden, Entwickler wunderbar zusammen arbeiten und lernen.
  • Welches BacklogItem sollten wir zuerst angehen? Ich hatte in einem zentralen Team eines Konzerns die Herausforderung, dass viele interne Kunden von diesem Team abhängig waren. Ich bat alle internen Kunden die Story mitzubringen, die für sie wichtig war. Die Kunden brachten alle Stories in eine Reihenfolge und begründeten die Position jeweils mit Wert und Wirkung. Einige Kunden haben darauf verzichtet Ihre Karten anzubringen, weil sie durch die Methode Transparenz darüber hatten, welche anderen wichtigen Aufgaben das Team erledigen müsste.
  • Welches TechnicalDebt Feld sollten wir zuerst lösen? Fördert den Austausch unter Entwicklern, um Fokus auf die wirklich wichtigen Technischen Schulden legen zu können. Zum Abschluss möchte ich noch ein Einsatzbeispiel zeigen, welches wirklich toll in die aktuelle OKR (Objektives & Key Results) Diskussion passt.

Magic Estimation – Als OKR Tool

Ich sehe einige OKR Implementierungen, die als Ziel haben mehr Ausrichtung an Unternehmenszielen, mehr Transparenz in übergreifenden Themen und Motivation für die Mitarbeiter zu erzeugen. Das lässt sich mit OKRs als Methode einfach und wirkungsvoll  erreichen. Allerdings muss dann die Kommunikation innerhalb des OKR Prozesses auch darauf ausgelegt sein.

Hierbei hilft die winzige Magic Estimation Herangehensweise.

In den Teams können die Dinge gesammelt werden, die im nächsten Quartal erreicht werden könnten. Im Rahmen einer Magic Estimation Session sortiert das Team diese Ziele in die gewünschte Reihenfolge.

Um die Key results zu finden, sammelt das Team jetzt noch „Dinge, an denen wir merken, dass das Objective erreicht wurde…” Damit sind die passenden Key results gefunden. Hier und da noch ein wenig Formulierungsmagic und schon ist das gut.

Übrigens können auch die Unternehmensziele und übergreifenden Objektives auf diesem Weg sehr interaktiv gefunden, sortiert und angereichert werden.

Magic Estimation oder diese Art einen Dialog einzurahmen und dadurch zu fördern ist für mich eine Methode geworden, die ich nicht missen möchte. Wo habe ich sie gelernt? In einem unserer Trainings… ganz am Anfang als ich noch nicht mal wusste wofür CSM steht. Schaut auch bei unseren Trainern und Trainings vorbei. Ich bin sicher, wir haben das passende Angebot auch für Dich!

Armin Schubert
Armin Schubert
Nach einigen Jahren in verschiedenen Führungspositionen habe ich 2012 Scrum kennengelernt und arbeite seit dieser Zeit als ScrumMaster und Agile Coach. Seit 2013 bin ich Geschäftsführer der Emendare GmbH & Co. KG und helfe Teams, Produkten und Unternehmen beim Einsatz von agilen Werten und Methoden. Insbesondere auf der Beziehungsebene des Teams sehe ich das größte Potential um positive Kräfte zu entfesseln.

armin.schubert@emendare.de

Alle Beiträge von Armin Schubert

Letzte Beiträge des Autors

  • Agile Coaching ist mehr als nur Scrum, Kanban und Backlog. Open Space für teamübergreifende Kommunikation.
  • Jedes Kind kann “sustainable pace”!
  • Ein Agile Coach Camp Wochenende voller Ideen, Impulse und Energie!
  • Community Arbeit entfesselt positive Kräfte!
  • 4 Wege, für die Weiterentwicklung in der wichtigen Rolle als ScrumMaster

Kontakt

Emendare GmbH & Co. KG
Karlstraße 87
76137 Karlsruhe

Tel.: +49 (0)721 170 280 08
Email: info@emendare.de

Service

Trainingsbuchung

Impressum

Datenschutzerklärung

Allgemeine Geschäftsbedingungen

Mehr von Emendare

www.scrummaster-ausbildung.de

Der Weg zu einer guten Priorisierung ist weit. Manchmal führt er über MoS...gutes PriorisierenBurnup ChartsMagische Burnup Charts und wo sie zu finden sind
Nach oben scrollen