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.
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):
- Du darfst nicht sprechen.
- Du darfst entweder ein BacklogItem vom Stapel nehmen und an der Wand einsortieren oder ein Backlogitem an der Wand umsortieren oder passen.
- 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.
Magic Estimation – die Dialogvariante
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″
Magic Estimation – weitere Einsatzfelder
- 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!