Magic Estimation vs. Planning Poker

Das Estimation Meeting ist ein wesentlicher Bestandteil im Scrum Flow. Zum einen sollen die Teammitglieder in diesem Meeting die User Stories kennenlernen, zum anderen soll aber natürlich auch der Funktionsumfang der User Stories geschätzt werden.

Wie schätzt man User Stories richtig und effizient?

Schätzung mit Planning Poker

Eine klassische Variante für die Schätzung im Scrum-Prozess ist die „Planning Poker“ Methode – manchmal auch „Scrum-Poker" genannt. Ziel ist es spielerisch Konsens über die Aufwände im Team zu erreichen. Die Teammitglieder schätzen dabei mit verdeckten Planning Poker Karten. So wird gewährleistet, dass dominante und ruhigere Typen unbeeinflusst ihre Schätzung abgeben können. Durch die verdeckte Schätzung nehmen alle Beteiligten aktiv teil und bringen ihr Wissen und ihre Erfahrungen in die jeweilige User Story mit ein.

Jedes Teammitglied erhält zu Beginn im Planning Poker ein Deck von Planning Poker Karten mit den Werten 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100. Die Werte repräsentieren Story-Points, Tage oder eine andere vereinbarte Einheit. Nach der Vorstellung des zu schätzenden Backlog Items, schätzen alle Teilnehmer für sich selbst und wählen eine entsprechende Karte aus. Anschließend werden die Karten in der Runde zeitgleich aufgedeckt. Sind die Schätzungen aller Teammitglieder gleich, wird der Wert direkt für die User Story übernommen. Weichen einige Schätzungen stark ab, sollte jeweils der Entwickler mit der niedrigsten und höchsten Schätzung seinen Wert begründen. Die Hintergründe werden anschließend in der Gruppe diskutiert bis ein Konsens erreicht wird oder weitere Informationen zur Aufgabe ermittelt werden konnten.

Wir bei LifeStyle haben Planning Poker seit der Einführung von Scrum im Unternehmen (Ende 2013) genutzt. Die Planning Poker Sitzungen haben bei uns jedoch durchschnittlich 1 bis 3 Stunden gedauert, weshalb wir den Zeitaufwand reduzieren und eine neue Schätzweise nutzen wollten. Daher haben wir nun seit November 2015 eine andere Methode, nämlich Magic Estimation eingeführt.

Magic Estimation vs. Planning Poker im Scrum-Prozess

Die Magic Estimation Methode nutzt auch Planning Poker Karten, setzt sie aber völlig anders ein. Bei dieser Methode verteilt man die Karten am Boden oder auf dem Tisch - die Teammitglieder selbst erhalten keine Karten mehr. Die Fibonacci-Zahlen auf den Karten stehen für die Funktionalitätsgröße der User Stories. Aufgaben, die mit 3 geschätzt werden, enthalten also 3x so viel Funktionalität wie User Stories mit dem Wert 1. Die gesamten Backlog Items werden an die Teammitglieder verteilt und - wenn benötigt - ein Timer gestartet. Die Teilnehmer schätzen die Funktionalitätsgröße für jede User Story und ordnen sie einer Karte mit dem passenden Wert zu. Haben alle Teammitglieder jede im Estimation Meeting enthaltene User Story kennengelernt und ihre eigene Schätzung vorgenommen, können die Werte diskutiert und die User Stories gemeinsam verschoben werden. Sind alle Unklarheiten ausgeräumt, werden die Story-Points auf die Aufgaben übertragen und die Priorisierung für das Scrum Backlog kann beginnen. Eine ausführliche Besprechung, wie die User Stories umgesetzt werden können, findet bei der Magic Estimation Methode bewusst nicht statt. Hintergrund ist die Tatsache, dass man beim Estimation Meeting noch gar nicht weiß welche User Stories überhaupt umgesetzt werden, daher soll man sich nicht zu lange mit Themen aufhalten, die im "Worst Case" sogar wieder verworfen werden.

Vorteile von Magic Estimation

Die Schätzung der User Stories erfolgt bei der Magic Estimation Methode deutlich schneller und bindet alle Teammitglieder durch den „sozialen Druck“ auch besser ein. Trotzdem ist die Art und Weise der Schätzung "demokratischer" als beim klassischen Planning Poker. Nach der „reinen“ Lehre der Methode findet die Schätzung still, aber in Bewegung statt, was die Schätzung fokussierter ablaufen lässt. Des Weiteren können zu große Backlog Items sehr schnell und sehr deutlich ausgemacht werden. Dadurch bekommt man schnell einen Überblick, welche User Stories noch in sinnvolle, kleinere Teile gesplittet werden müssen. Diese werden dann wiederum im nächsten Magic Estimation Meeting geschätzt.

Fazit

Wir haben die „reine“ Lehre abgewandelt und gute Erfahrungen damit gemacht, dass sich die Teilnehmer kurz über die User Stories austauschen und damit der Product Owner bereits wertvolles Feedback über die Story erhält. Unsere Estimation Meetings konnten wir durch den Einsatz der Magic Estimation Methode von 1 bis 3 Stunden auf 15 bis maximal 30 Minuten reduzieren. In kürzerer Zeit können wir mit der neuen Methode die gleiche, manchmal so gar eine größere Anzahl an User Stories schätzen. Unsere anfänglichen Bedenken, dass die Genauigkeit bei dieser Methode leiden könnte, wurde nicht bestätigt. Beim klassischen Planning Poker haben wir oft viel Zeit damit verbracht, Stories zu besprechen, die überhaupt nicht umgesetzt wurden. Dieser Aspekt fällt bei Magic Estimation durch geringe Dauer und die hohe Produktivität nicht ins Gewicht.

Magic Estimation ist für uns ganz klar ein Royal Flush.