Magic Estimation: Aufwände agil im Team schätzen
In agilen Teams wird der Aufwand von Aufgaben bzw. User Stories häufig mithilfe von Story Points geschätzt. Die Magic Estimation Methode bietet hierfür einen praktischen und schnellen Ansatz. In diesem Artikel erklären wir, wie die Methode funktioniert, was zu beachten ist und wo die Unterschiede zu anderen Schätzmethoden wie Planning Poker liegen.
Inhalt der Seite
- Was ist eine „Magic Estimation“?
- Vorbereitung: Was wird für eine Magic Estimation benötigt?
- Schritt-für-Schritt: Ablauf der Magic Estimation Methode
- Vorteile und Grenzen von Magic Estimation
- Planning Poker vs. Magic Estimation: Die Unterschiede
- Tipps für die erfolgreiche Durchführung einer Magic Estimation
- Häufige Fragen rund um Magic Planning:
- Zusammenfassung
Was ist eine „Magic Estimation“?
Magic Estimation, auch Magic Planning genannt, ist eine Methode aus der agilen Softwareentwicklung und dem Produktmanagement, um den Arbeitsaufwand für eine Vielzahl von User Stories oder Aufgaben in einem Product Backlog schnell und effizient zu schätzen. Das Format zeichnet sich besonders durch seine Geschwindigkeit und den Einsatz der kollektiven Intelligenz der Teilnehmenden aus.
Vorbereitung: Was wird für eine Magic Estimation benötigt?
Zunächst muss sichergestellt werden, dass alle zu schätzenden User Stories bereits definiert und auf Karten oder Zetteln notiert sind. Diese Stories dienen als Grundlage für die Schätzung. Außerdem ist es wichtig, ein Team von 3 bis 10 Personen zu haben, die an dem Prozess teilnehmen und das nötige Fachwissen bzw. die richtigen Perspektiven für eine gute Schätzung mitbringen.
Ein wesentlicher Bestandteil des Prozesses sind Karten oder Markierungen mit den gewählten Story-Point-Werten, wie z. B. 1, 2, 3, 5, 8, 13, 20, 40 und 100, die als Referenzpunkte für die Schätzung dienen. Klebepunkte oder Marker werden benötigt, um User Stories zu markieren, bei denen während des Prozesses Meinungsverschiedenheiten oder Unsicherheiten auftreten. Diese können dann später im Team diskutiert werden.
Ein großer Tisch oder genügend Wandfläche wird benötigt, um sowohl die Story Point Karten als auch die User Stories übersichtlich aufhängen zu können. Obwohl Magic Estimation als schnelle Schätztechnik gilt, sollte je nach Anzahl der User Stories mit einem Zeitaufwand von 1 bis 1,5 Stunden gerechnet werden.
Optional kann ein Moderator, Scrum Master oder Agile Coach hinzugezogen werden, um den Prozess zu leiten, Fragen zu klären und den Fokus des Teams aufrechtzuerhalten. Nach Abschluss der Schätzung sollten die Ergebnisse in einem digitalen Tool oder einem analogen Whiteboard dokumentiert werden.
Schritt-für-Schritt: Ablauf der Magic Estimation Methode
Zuerst legt das Team die Karten mit den vorgegebenen Story Point-Werten (sortiert nach ihrer Größe) in einer Reihe aus. Die Abstände zwischen den Karten spiegeln idealerweise die Unterschiede zwischen den Point-Werten wider, sodass beispielsweise die Abstände zwischen den Karten für 1 und 2 Punkte geringer sind als zwischen 13 und 40 Punkten.
Vor dem eigentlichen Schätzprozess wählt das Team eine Referenz-User-Story aus, die als Richtwert für die anderen Stories dient. Die Schätzung dieser Referenz-Story erfolgt meistens mithilfe einer anderen Technik, etwa dem Planning Poker. Dies gibt dem Team einen Anhaltspunkt, um die Komplexität und den Aufwand der anderen User Stories besser einschätzen zu können.
Als (Nutzer/Rolle) möchte ich (Funktion), um (Nutzen/Wert) …
Mit dieser Basis beginnt der Kernprozess der Magic Estimation: das stille Schätzen. Die Teammitglieder nehmen die vorbereiteten User Stories und ordnen sie intuitiv den entsprechenden Story-Point-Karten zu. Während dieser Phase wird nicht gesprochen; es geht darum, auf das eigene Bauchgefühl zu hören und nicht von Diskussionen abgelenkt zu werden.
Sobald ein Teammitglied mit seinen eigenen Stories fertig ist, überprüft es die Einschätzungen der Kollegen. Bei Meinungsverschiedenheiten oder Unsicherheiten wird die betreffende User Story mit einem klebenden Punkt markiert, um später darüber zu sprechen.
Nachdem alle User Stories zugeordnet und überprüft wurden, beginnt die Diskussionsphase. Hier bespricht das Team die markierten Stories, tauscht Argumente aus und einigt sich auf eine finale Einschätzung in Story Points. Dabei werden unterschiedliche Perspektiven und Erfahrungen genutzt, um zu einem Konsens zu kommen.
Vorteile und Grenzen von Magic Estimation
Der Hauptvorteil der „Magic Estimation“ liegt in ihrer Effizienz. Teams können in kurzer Zeit eine große Anzahl von User Stories schätzen. Außerdem profitieren alle Mitglieder von der gleichberechtigten Teilnahme, was den Prozess inklusiver und demokratischer macht.
Ein weiterer Vorteil ist die Zusammenarbeit und der Konsensfindungsprozess nach der stillen Schätzphase. Dadurch, dass die Teammitglieder die Möglichkeit haben, die Schätzungen der anderen zu überprüfen und zu diskutieren, wird ein kollektives Verständnis der User Stories und ihrer Komplexität gefördert. Dies kann auch dazu beitragen, versteckte Probleme oder Herausforderungen aufzudecken, die einem einzelnen Teammitglied möglicherweise entgangen sind.
Allerdings hat die Magic Estimation auch ihre Grenzen. Einer der Hauptnachteile ist, dass sie möglicherweise nicht für jedes Team oder jede Art von Projekt geeignet ist. In Situationen, in denen eine eingehende Diskussion und Analyse erforderlich ist, um ein klares Verständnis einer User Story zu erlangen, kann die Methode zu oberflächlich sein. Darüber hinaus kann der Mangel an verbaler Kommunikation während der stillen Schätzphase dazu führen, dass wichtige Kontextinformationen oder Bedenken nicht sofort geteilt werden.
Ein weiterer Aspekt, der berücksichtigt werden muss, ist die Erfahrung und das Fachwissen des Teams. Magic Estimation setzt voraus, dass die Teammitglieder über genügend Wissen und Erfahrung verfügen, um Aufgaben intuitiv einschätzen zu können. Ohne diese Grundlage kann die Methode zu ungenauen oder inkonsistenten Schätzungen führen.
Planning Poker vs. Magic Estimation: Die Unterschiede
Sowohl Planning Poker als auch Magic Estimation sind agile Schätzungsmethoden, um den Aufwand von Arbeitspaketen (User Stories) zu bestimmen.
Planning Poker, auch bekannt als Scrum Poker, ist eine konsensbasierte Technik, bei der jedes Teammitglied eine Karte aus einem Kartensatz auswählt, um den Aufwand einer User Story zu schätzen. Die Karten werden gleichzeitig aufgedeckt, und wenn die Schätzungen auseinandergehen, wird darüber diskutiert, bis ein Konsens erreicht ist. Der Hauptvorteil dieser Methode ist die offene Kommunikation und Diskussion, die sie fördert. Es ermöglicht den Teammitgliedern, ihre Gedanken, Bedenken und Überlegungen offen zu teilen und voneinander zu lernen. Dies kann zu einem tieferen Verständnis der User Story und den damit verbundenen Herausforderungen führen.
Magic Estimation hingegen setzt auf einen stilleren und schnelleren Ansatz. Der zentrale Unterschied zwischen den beiden Techniken ist also der Kommunikationsansatz. Während Planning Poker eine fortlaufende Kommunikation und Diskussion während des gesamten Schätzungsprozesses fördert, konzentriert sich Magic Estimation zunächst auf individuelle, stille Reflexionen und verschiebt die Diskussionen auf einen späteren Zeitpunkt.
Beide Methoden haben ihre Stärken und Schwächen. Man könnte es aber so zusammenfassen:
Planning Poker …
… ist sinnvoll, wenn eine kleine Anzahl von Aufgaben bzw. User Stories geschätzt werden soll und eine genaue Schätzung inklusive Diskussion im Team explizit erwünscht ist. PP bietet sich daher im Sprint Planning an, um ein gemeinsames Verständnis der zu erledigenden Stories aufzubauen.
Magic Estimation …
… bietet sich an, wenn eine große Anzahl von Aufgaben bzw. User Stories grob geschätzt werden sollen. Ein detaillierter Austausch pro Story wird hier nicht benötigt. Dafür kann in relativ kurzer Zeit der Arbeitsaufwand eines kompletten Backlogs überschlagen werden.
Tipps für die erfolgreiche Durchführung einer Magic Estimation
- Zweck und Ziel verstehen: Es ist wichtig, dass alle Teammitglieder den Zweck der Magic Estimation verstehen. Es geht nicht darum, genaue Zeitschätzungen zu erhalten, sondern vielmehr darum, relative Größen von User Stories zu ermitteln.
- Einheitliche Vorbereitung: Sorgen Sie dafür, dass alle User Stories, die geschätzt werden sollen, klar und verständlich formuliert sind. Unklare oder zu allgemeine Beschreibungen können zu Verwirrung und inkonsistenten Schätzungen führen.
- Referenz-Story festlegen: Bestimmen Sie zu Beginn eine Referenz-Story, die allen Teammitgliedern bekannt ist. Diese dient als Ankerpunkt für die Schätzungen und sorgt für Konsistenz.
- Zeitbeschränkung einhalten: Setzen Sie eine klare Zeitgrenze für den Schätzungsprozess. Dies fördert die Effizienz und verhindert, dass sich das Team in endlosen Diskussionen verliert.
- Vermeiden Sie Gruppendenken: Auch wenn die Schätzungen im Stillen durchgeführt werden, kann es vorkommen, dass einige Mitglieder einfach den Schätzungen anderer folgen, ohne eigene Überlegungen anzustellen. Ermutigen Sie das Team, unabhängige Entscheidungen zu treffen.
- Nach der Schätzung kommunizieren: Nachdem die stille Schätzung abgeschlossen ist, ist es wichtig, über die Ergebnisse zu diskutieren, besonders wenn es deutliche Unterschiede in den Schätzungen gibt.
- Schätzungen regelmäßig überprüfen: Wie bei allen Schätzungstechniken kann es vorkommen, dass sich im Laufe der Zeit neue Erkenntnisse ergeben. Planen Sie regelmäßige Überprüfungen ein, um die Schätzungen bei Bedarf anzupassen.
Häufige Fragen rund um Magic Planning:
Wie verhalten sich Story Points zu tatsächlicher Entwicklungszeit?
Story Points sind eine relative Maßeinheit und nicht direkt mit Zeitaufwand gleichzusetzen. Es geht um die Komplexität und den relativen Aufwand im Vergleich zu anderen Stories.
Können wir statt Story Points auch andere Werte verwenden?
Das ist kein Problem. Es können auch T-Shirt-Größen (S, M, L, XL, XXL), richtige Zeitschätzungen (Stunden, Tage, Wochen) oder jede andere Art von Größeneinordnung verwendet werden. Das Grundprinzip bleibt das gleiche, solange alle Teammitglieder die Einteilungen gleichermaßen verstehen.
Was tun, wenn es viele Unstimmigkeiten bei den Schätzungen gibt?
Dies ist ein Zeichen dafür, dass die User Story möglicherweise nicht klar genug ist oder unterschiedlich interpretiert wird. Eine Diskussion kann hier Klarheit schaffen. Unter Umständen muss der Product Owner die Story im Nachhinein schärfen oder unterteilen.
Zu welchem Zeitpunkt sollten wir die Methode verwenden?
Das Format eignet sich gut zu Beginn eines Projektes bzw. einer größeren Initiative innerhalb des Produktteams. Dann gibt es meist eine Vielzahl von Aufgaben, die noch nicht über eine (grobe) Aufwandsschätzung verfügen. Auch nach einem User Story Mapping kann eine Magic Estimation helfen, um direkt Arbeitsaufwände für die Elemente der zuvor erstellten Story Map zu schätzen.
Die Methode sollte jedoch nicht im Rahmen der Sprint-Planung verwendet werden. Das Backlog Refinement bietet sich hier viel besser an, um den Umfang und Fokus der Sprint Planung nicht zu sprengen.
Zusammenfassung
Die Magic Estimation ist eine agile Methode zur schnellen und effizienten Schätzung des Arbeitsaufwands von User Stories. Dabei werden User Stories in relativen Einheiten, den sogenannten Story Points, eingeschätzt. Im Unterschied zu anderen Techniken findet die Schätzung hier in Stille statt, wodurch Beeinflussungen und längere Diskussionen vermieden werden. Nach einer initialen selbstständigen Zuordnung der User Stories zu Story Points durch jedes Teammitglied, folgt eine Überprüfungsphase, in der Unterschiede in den Schätzungen diskutiert und angeglichen werden. Die Methode eignet sich besonders, um in kurzer Zeit eine große Menge an User Stories zu schätzen und fördert die Unabhängigkeit sowie das kritische Denken jedes Teammitglieds.