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!
