Das Magic Estimation Verfahren ist ein ideale Methode, um eine schnelle Schätzung für eine große Menge an Backlog Items durchzuführen.
Die Methode eignet sich besonders für:
- Initialschätzungen von Projekten,
- die Schätzung einer großen Anzahl von Backlog Items oder
- der Mittelfristplanung für dein Projekt.
Die Technik ist auch deshalb so schnell, weil während des Schätzens wenig bis gar nicht gesprochen werden darf. Somit kommen keine zeitaufwändige Diskussion zustande.
Was ist Magic Estimation
Magic Estimation wurde von Boris Gloger als Gegenentwurf zu komplizierteren Schätzverfahren, wie z.B. Planning Poker, entwickelt. Es basiert dabei auf dem Affinity Estimation von Lowell Lindstrom.
Das Schätzverfahren hat den Anspruch, in kurzer Zeit eine gute Schätzung hinsichtlich Komplexität und Aufwand für eine große Menge an Backlog Items zu erhalten.
Eine vorher festgelegte Schätzskala, z.B. die Fibonacci Reihe, wird mittels PostIts an die Wand gebracht. Danach wird eine Referenzstory eingeordnet und restlichen Backlog Items werden relativ zu dieser aufgehangen.
Die Methode verzichtet dabei explizit auf langwierige Diskussionen. Das Schätzverfahren wird größtenteils nonverbal durchgeführt.
Unterschied zum Planning Poker
Planning Poker ist ein sehr detailliertes und diskussionsreiches Verfahren. Es ist ideal für die Vorbereitung des nächsten Sprints und für Schätzungen in kleinen Teams.
Magic Estimation ist ein eher oberflächliches Schätzverfahren, bei welchem eher weniger diskutiert wird. Es zeigt sehr schnell Verhältnisse auf. Als Product Owner kannst du gut erkennen, was wahrscheinlich die größten und aufwändigsten Backlog Items sein werden.
Vor und Nachteile von Magic Estimation
Wie jede Methodik hat der Einsatz von Magic Estimation auch seine Vor- und Nachteile.
Vorteile:
- sehr schnelle Schätzmethode
- Ideal für eine initiale Schätzung des Backlogs
- es kann eine große Menge an Backlog Items geschätzt werden
- als Product Owner bekommst du schnell Feedback, wo wahrscheinlich die größte Komplexität liegt
Nachteile:
- sehr oberflächliche Schätzmethode
- Details in Backlog Items können übersehen werden
- fachliche Anforderungen können vom Team nicht immer durchdrungen werden
Schätzmaße und -einheiten
Es können verschiedene Schätzmaße für das Magic Estimation genutzt werden. Wichtig ist nur, dass das Team mit diesen umgehen kann und die Verhältnismäßigkeit innerhalb der Skala klar ist.
Die gängigsten Schätzmaße sind dabei T-Shirt Größen (XS, S, M, L, XL , XXL) oder Fibonacci Zahlen (1, 2, 3, 5, 8, 13, 20, 40, 100).
Geschätzt wird dabei in der Regel Komplexität und nicht zeitlicher Aufwand.
Folgende Tabelle stellt die Schätzmaße gegenüber.
| T-Shirt Größe | Story Points* | Beschreibung | Art der Anforderung |
|---|---|---|---|
| – | 0 | – | geschenkt, Story wurde bereits umgesetzt |
| XXXS | 1 | 4x so klein | einfacher Bug, triviale Story |
| XXS | 2 | 2x so klein | sehr einfache Story |
| XS | 3 | extra klein | einfache Story |
| S | 5 | klein | normale Story, etwas kleiner |
| M | 8 | mittel | normale Story |
| L | 13 | groß | normale Story, etwas größer |
| XL | 20 | extra groß | übergroße Story |
| XXL | 40 | 2x so groß | überdimensionierte Story |
| XXXL | 100 | riesig | Epic |
| *Pseudo Fibonacci |
Für das Magic Estimation solltest du also eine Referenzstory wählen, die in etwa der „normalen Story“ entspricht, also eine „M“ als T-Shirt oder eine 8 in Storypoints.
Magic Estimation – Vorbereitung
Bevor du ein Schätzmeeting mit dieser Methode beginnst, solltest du die folgenden 3 Punkte erledigen:
- Deine Backlog-Items vorfiltern
- Die Backlog-Items auf Karten bringen (oder in ein Whiteboard bei Online Meetings)
- Ein Referenz-Item festlegen
Backlog-Items vorfiltern
Magic Estimation ist eine Methode, mit der du viele Backlog-Items in kurzer Zeit schätzen kannst. Trotzdem solltest du deine zu schätzenden Items auf ein vernünftiges Maß reduzieren.
Was ist die Zielstellung des Meetings? Soll der nächste Release geschätzt werden? Oder alle Pflichtfeatures des Kunden?
Wenn du mehr zu dem Thema erfahren möchtest und welche Methoden hier sinnvoll sind, kannst du dir meinen Artikel zum Thema Vorbereitung des Backlog Refinements anschauen.
Backlog-Items auf Karten bringen
Als nächstes solltest du die zu schätzenden Items auf physische oder virtuelle Karten bringen. Auf der Karte sollten der Titel des Backlog Items und eine kurze Beschreibung stehen.
Am Beispiel einer Story wäre das der Name der Story und die Userstory im Format „Als <Rolle> möchte ich <Aktion> tun, um <Mehrwert> zu erreichen“.
So können die Teilnehmer schnell sehen, um was es geht und es kommen weniger Fragen auf.
Referenz-Item festlegen
Als letzten Schritt solltest du im Vorfeld ein Referenz-Item festlegen. Idealerweise machst du das im Team.
Das Item sollte in der Form sein, dass es
- im Team bekannt ist
- eine häufig umzusetzende Anforderung wiederspiegelt und
- vom Aufwand her etwa in der Mitte des Schätzspektrums liegt
Falls das Referenz-Item nicht im Vorfeld festgelegt wird, dann kann es auch zum Beginn des Meetings ermittelt werden.
Magic Estimation – Zeitaufwand und Ablauf
Für diese Schätzmethode solltest du dir zwischen 60 und 120 Minuten Zeit nehmen.
Das Vorgehen ist dabei wie folgt :
(es wird ein Präsenzworkshop beschrieben, die Online Variante kann davon aber einfach abgeleitet werden)
- Phase 0 – Vorbereitung und Einleitung – 10 bis 20 Minuten
- An einer Wand oder einer Metaplan-Wand werden die Maßeinheiten für die Schätzung von links nach rechts aufgehängt
- Der Product Owner stellt alle zu schätzenden Backlog Items kurz vor (in der Regel Titel und User Story)
- (falls noch nicht vorhanden) ein Referenz
- Phase 1 – Initiales Platzieren der Backlog Items – keine verbale Kommunikation zwischen den Teammitgliedern – 10 bis 20 Minuten
- Jedes Teammitglied kann sich ein Backlog Item nehmen und es unter eines der Maße hängen
- Ist ein Teammitglied nicht mit der Schätzung einverstanden, kann es diese umhängen
- Wird ein Backlog Item umgehangen, dann macht der Moderator (oder Scrum Master) einen Punkt auf die Karte
- Sind alle Karten aufgehangen und es gibt keine/kaum Bewegung mehr, dann wird in Phase 2 übergegangen
- Phase 2 – Diskussion zu den uneindeutigen Backlog Items – 30 bis 60 Minuten
- Der Moderator (oder Scrum Master) nimmt alle Backlog Items, welche sich häufig bewegt haben
- Die Person mit der niedrigsten und der höchsten Schätzung diskutieren ihre Standpunkte. Kommt es zu einer Einigung, so wird die Karte an der entsprechenden Stelle aufgehangen. Kommt es zu keiner Einigung, muss die Karte detailliert und später geschätzt werden.
Magic Estimation Online durchführen
Magic Estimation lässt sich auch in verteilten Teams Online durchführen. Hierzu stehen verschiedene Möglichkeiten zur Verfügung.
Magic Estimation – Online Whiteboard
Die einfachste und komfortabelste Lösung ist ein Online Whiteboard. Falls du nicht sicher bist, welches Whiteboard für dich das richtige ist, findest du hier eine Auswahl.
Als Vorbereitung sollten alle zu schätzenden Stories als kleine Notizzettel in eine Art Backlog geschoben werden.
Die Teilnehmer können dann die Stories daraus nehmen und auf die entsprechende Schätzung verschieben.
Magic Estimation – PowerPoint
Falls ein Online Whiteboard nicht zur Verfügung steht, kann auch Microsoft Powerpoint genutzt werden.
Wichtig dafür ist, dass alle Teilnehmer auf die Powerpoint Datei zugreifen können.
Analog zum Online Whiteboard sollten als Vorbereitung alle zu schätzenden Stories als kleine Notizzettel in eine Art Backlog geschoben werden. Die Teilnehmer können dann die Stories daraus nehmen und auf die entsprechende Schätzung verschieben.
Magic Estimation – Jira Plugin
Das De-Facto Standardtool zur Verwaltung von Anforderungen in agilen Projekten ist JIRA von Atlassian. Leider werden Schätzverfahren im Standard nicht gut unterstützt. Zum Glück gibt es für jede Lücke mindestens ein Plugin, welches diese schließt.
Für Magic Estimation kann ich folgende 2 Plugins empfehlen:
- Agile Poker for Jira – bis 10 Nutzer kostenfrei, danach $2,50 pro Nutzer
- Magic Estimations – kostenfreie App
Grenzen von Magic Estimation
Magic Estimation hat seine Grenzen. Es ist eine Methode, welche auf Schnelligkeit und Intuition setzt. Deshalb ist es für eine erste Schätzung oder ein Vor-Refinement sehr sinnvoll.
Grenzen:
- da über viele Stories nicht diskutiert wird, können leicht Risiken oder Unbekannte übersehen werden
- je nach Teilnehmergruppe können wichtige Sichtweisen fehlen (falls z.B. Entwickler nicht mit dabei sind)
- für eine Sprintplanung ist die Diskussionstiefe zu gering. Hier sollte sich für jede einzelne Story Zeit gelassen werden
- es erfolgt keine Aufteilung von Stories. Dies ist vor allem bei hohen Schätzungen vor einer Umsetzung im Sprint sinnvoll.
Fazit
Magic Estimation ist eine sehr gute Methode, um dein Backlog schnell und effizient schätzen zu lassen. Es hilft, die größten und aufwändigsten Anforderungen zu identifizieren. Somit weißt du sehr schnell, auf welche Bereiche du dich konzentrieren musst.
Auch für eine Priorisierung und eine Abstimmung mit dem Kunden sind die Ergebnisse eine Magic Estimation Session mehr als ausreichend.
Zum Weiterlesen:
Recent comments