In welchem Monat sollen die Marketingmaßnahmen zu Feature X starten? Wie viel Budget muss das Management für eine bestimmte Innovation bereitstellen? Und welche Anzahl an Tasks kann unser Team überhaupt schaffen? Im Projektverlauf wird das Team immer wieder mit Fragen zur mittelfristigen Planung konfrontiert – insbesondere zu Projektbeginn eine schwierige Aufgabe, da zahlreiche relevante Informationen noch fehlen. Das Schätzverfahren „Magic Estimation“ ist ein bewährtes Werkzeug, um eine agile Arbeitsweise und mittelfristige Planungen in Einklang zu bringen.
Mittelfristige Planung und Agilität – ein Widerspruch?
In unserer dreiteiligen Serie rund um das Thema Aufwandsschätzung haben wir uns ausführlich damit beschäftigt, warum Schätzen und Planen auch in agilen Projekten wichtig ist und wo die Unterschiede zur traditionellen Herangehensweise liegen. Ein großes Missverständnis ist, dass Unternehmen bei einer Umstellung auf agiles Arbeiten künftig nur noch „von Sprint zu Sprint“ planen dürfen. Auch in agilen Projekten gibt es eine mittel- bis langfristige Planung, lediglich die Detailgenauigkeit nimmt mit dem Zeithorizont ab.
Das macht Sinn, denn während die nächste Iteration – also ein Zeitraum von ein bis vier Wochen – sehr exakt planbar ist, kann der dritte, vierte oder fünfte Sprint heute unmöglich realistisch beschrieben werden. Vor dem Hintergrund, dass Projektleiter in klassischen Projekten bis zu 30 Prozent ihrer Zeit mit der (Um-)Planung verbringen, minimiert eine agile Methode aufwändige und unnötige Aktualisierungen von Projektplänen und vermeidet ein falsches Gefühl von Kontrolle und Sicherheit.
Magic Estimation vs Planning Poker
Nichtsdestotrotz müssen auch agile Teams über die nächsten vier Wochen hinaus planen und größere Backlogs noch nicht genauer spezifizierter User Stories schätzen. Der bekannte Planning Poker eignet sich hier nicht, da der nötige Detailgrad für mittelfristige Etappenziele nicht vorliegt. Außerdem würde sich die Länge der Estimation Meetings durch die beim Planning Poker gewünschten Diskussionen unnötig in die Länge ziehen.
Eine hervorragende Alternative ist „Magic Estimation“, eine Methode, die sowohl von Teams in mittelständischen Unternehmen als auch in Konzernen gerne eingesetzt wird. Zwar sollten auch hier die Ziele der priorisierten User Stories, der Kontext („Epic“) und die ersten wesentlichen Akzeptanzkriterien kurz vorgestellt werden, aber eine ausführliche Besprechung wie beim Planning Poker findet bewusst nicht statt.
Der Ablauf von Magic Estimation
- Die Karten mit den User Stories werden gleichmäßig an die Teammitglieder verteilt.
- Ein Satz Planning-Poker-Karten wird auf dem Boden oder einem großen Tisch ausgelegt. Die Fibonacci-Zahlen auf den Karten stehen wie beim Planning Poker für die Anzahl der Story Points der User Stories, üblicherweise mit den Werten 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100. Eine User Story, die mit „3“ geschätzt wird, ist also voraussichtlich dreimal so aufwändig wie User Stories mit dem Wert „1“ – abhängig von Größe, Komplexität und Unsicherheit (mehr zu dieser relativen Schätzungsmethode können Sie in unserem Blogbeitrag hier nachlesen).
- Nach dem Starten eines Timers (10 bis 15 Minuten) schätzen die Teammitglieder jede ihrer User Stories und legen sie auf der Skala bei der Karte mit dem passenden Wert ab. Während die Zeit läuft, finden keine Diskussionen untereinander statt.
- Sind die Stories zugeordnet, startet eine zweite Runde: Jetzt hat jedes Teammitglied die Möglichkeit, Schätzungen anderer Teammitglieder durch Verschieben zu korrigieren (ebenfalls schweigend).
- Der Product Owner nimmt User Stories aus dem Spiel, die am Ende ständig hin- und hergeschoben werden – diese Items werden anschließend gemeinsam diskutiert, um eine Einigung zu erzielen und die Storys final auf dem Kartenstrahl anzuordnen.
Vorteile von Magic Estimation
- Es entsteht selbst bei großen Backlogs sehr fokussiert und effizient eine initiale Projektschätzung.
- Das Team wird in die mittelfristige Planung einbezogen, was erfahrungsgemäß zu realistischeren Planungen führt.
- Alle Teammitglieder werden gleichberechtigt eingebunden.
- Da zu diesem Zeitpunkt noch gar nicht klar ist, welche User Stories überhaupt umgesetzt werden, hält sich das Team nicht mit unnötigen Diskussionen auf – trotzdem erkennt der Product Owner schnell, welche User Stories noch in sinnvollere, kleinere Teile gesplittet oder zu einem späteren Zeitpunkt genauer definiert werden müssen.