Agile Series: Das Backlog mit Magic Estimation schätzen

Foto des Autors
Thorsten Kamann

Wenn Sie eine große Anzahl an Epics oder Stories in Ihrem Backlog schätzen müssen, ist Planning Poker nicht immer die beste Wahl. In diesem Artikel lernen Sie Magic Estimation kennen, eine Schätzmethode, mit der Sie in der Lage sind, große Mengen an Epics und/oder Stories in kurzer Zeit zu schätzen.

Im vorherigen Teil dieser Serie habe ich Ihnen Schätzgrößen und eine erste Schätzmethode, das Planning Poker, vorgestellt. Planning Poker eignet sich hervorragend für eine kleinere Menge – und vor allem schon detailliert spezifizierte – Backlog Items, wie User Stories. Befinden Sie sich jedoch noch sehr früh in einem Projekt und benötigen eine erste Schätzung, bietet sich eine andere Schätzmethode mit dem Namen Magic Estimation an, die es ermöglicht, eine große Anzahl von Items – oft sind das Epics –  in kurzer Zeit zu schätzen.

Mit den richtigen Schätzmethoden und der richtigen Vorbereitung auf einen Schätztermin ist es aus meiner Erfahrung recht simpel, selbst eine große Anzahl von Anforderungen oder sogar das gesamte Backlog schnell zu schätzen. Denn so gut es ist, den nächsten Sprint geschätzt zu haben, richtig toll ist es erst, wenn das gesamte Backlog einmal geschätzt worden ist. Und ich meine nicht erst dann, wenn das Projekt fertig ist!

Magic Estimation: So klappt es garantiert

Weil beim Planning Poker doch sehr viel Detailklärungen und Diskussionen aufkommen, ist das Pokern dafür weniger geeignet. Schnell eine große Anzahl an Stories oder Epics zu schätzen funktioniert am besten mit Magic Estimation.

Zur Vorbereitung nehme ich eine große Pinnwand: Ich markiere Swimlanes, die den Storypoints oder T-Shirt-Größen entsprechen. T-Shirt-Größen sind für die Schätzung von Epics gut geeignet, da hier ein Bereich geschätzt wird, zum Beispiel von Storypoints. T-Shirt-Größe S wäre z.B. der Bereich zwischen 1 und 13 Punkten, M von 14 bis 29 oder XXL zwischen 101 – 150 Storypoints (siehe untenstehende Tabelle). Hier gilt: Je größer das T-Shirt desto unschärfer die Schätzung. Alle Items sind auf Karteikarten (oder ausgedruckt und ausgeschnitten auf Papier) vorbereitet.

T-Shirt GrößeStorypoints-BereichT-Shirt GrößeStorypoints-Bereich
S1 – 13  XL69 – 100
M14 – 29  XXL101 – 150
L30 – 68  
Tabelle 1: Beispielwerte für T-Shirt-Größen

Und so geht es dann in den Workshop: Jeder Teilnehmer nimmt sich eine Handvoll dieser Karten und pinnt diese auf die Swimlane, an die Stelle, die seiner Schätzung entspricht. Diese Schätzungen müssen nicht diskutiert werden – wer die Karte aufhängt, gibt damit sein Statement ab. Hat jeder seine Karten verteilt, schauen wir uns gemeinsam das Ergebnis an. Ist jemand der Meinung, dass eine Karte anders eingeschätzt werden sollte, kann er diese korrigieren und auf eine andere Swimlane hängen. Dabei soll die Karte mit einem roten Punkt markiert werden, wenn eine höhere Swimlane gewählt worden ist oder mit einem grünen Punkt, wenn es einen niedrigeren Schätzwert für das Item geben soll. Nur die Karten, die mehrere grüne oder rote Punkte bekommen haben, möchte ich dann noch einmal diskutieren. Bei Karten ohne größere Korrekturen, nehme ich an, dass der Schätzwert für alle einigermaßen stimmt.

Schätzreferenz festlegen

Wenn Sie noch früh in einem neuem Projekt oder in einer neuen Produktentwicklung sind, wird es Ihnen schwerfallen die Items auf die richtige Größe zu schätzen. Sowohl Planning Poker wie auch Magic Estimation basieren auf Vergleichswerten, d.h. Sie ordnen einem Item einen Schätzwert im Verhältnis zu einer Referenz zu. In einem neuen Projekt müssen Sie diese Referenz erst einmal schaffen. Aber auch das lässt sich einfach bewerkstelligen.

Dazu schaue ich mir mit Experten die Liste der Epics an, die bisher erstellt worden sind. Die Experten wählen ein Epic aus dieser Liste aus, welches nicht zu einfach, aber auch nicht zu komplex ist. Zu diesem Epic schreiben wir potentielle User Stories auf und schätzen diese auf Basis von Storypoints. Wenn Sie auch für User Stories noch keine Referenz haben, lesen Sie den nächsten Abschnitt.

Die Summe der Storypoints (plus sinnvollem Risikoaufschlag) ergibt einen Wert, den ich dann der Liste der T-Shirt-Größen zuordne. Am besten ist es, wenn sich das gewählte Epic im mittleren Bereich (T-Shirt-Größe L) befindet. Zu groß oder zu klein erschwert die Zuordnung der anderen Epics, da man entweder nach oben oder unten nicht mehr genügend Platz auf der Skala hat.

Das Vorgehen, welches ich für die Ermittlung einer Referenz-User-Story wähle, ähnelt dem für das Referenz-Epic. Der Unterschied besteht darin, dass ich alle To-dos, die notwendig sind, um eine Story zu erledigen, ermitteln und die Story mit Storypoints aus der klassischen Fibonacci-Reihe schätzen lasse.

Warum es gut ist, das ganze Backlog einmal durchzuschätzen

Warum halte ich es überhaupt für so wichtig, das Backlog durchzuschätzen? Der indikative Gesamtaufwand ist ein guter Wegweiser für die Priorisierung der Arbeit. Für eine Roadmap ist es wichtig zu wissen, oder vielleicht wenigstens zu ahnen, in welcher Größenordnung man sich bewegt. Nur auf das Prinzip “Schaun wir mal” zu bauen, führt aus meiner Praxiserfahrung früher oder später zu Problemen. Es ist auch kein allzu großer Aufwand: Ein bisschen Vorbereitung und genau ein Workshop reichen schon für ein durchgeschätztes Backlog aus. Deshalb ist dieser Workshop „magisch”.

Im nächsten und letzten Teil zum Thema Schätzmethoden, stelle ich ein Verfahren vor, das sich für erfahrene Teams besonders eignet und den Schätzaufwand drastisch reduziert.

1 Gedanke zu „Agile Series: Das Backlog mit Magic Estimation schätzen“

  1. Guter Artikel! Die Methode habe ich auch schon an der einen oder anderen Stelle in Teams angewandt und Erfolge bzw. Aha-Effekte damit erzielt. Einfach umzusetzen!

    Antworten

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Agilität braucht gute Führung

Agilität braucht gute Führung

Die agile Führungskraft ermöglicht, dass er sich entwickeln und seine Arbeit bestmöglich erledigen kann. Wie es im agilen Manifest steht: ...
Kamil Sokolski bei einem ruhigen Gespräch mit einem Arbeitskollegen im Conciso Workgarden im agilen Kontext. Zusätzlich wird das Conciso Logo in der unteren rechten Ecke abgebildet. Das Bild wird in dem Wissensbeitrag "Agilität ganzheitlich denken, statt nur „PS auf die Straße bringen“." genutzt.

Agilität ganzheitlich denken, statt nur „PS auf die Straße zu bringen“...

Agile Coach Kamil Sokolski erklärt, weshalb es wichtig ist, Agilität ganzheitlich zu denken ...
Wie Sie den MVP-Ansatz für vorhandene Anwendungen nutzen können

Wie Sie den MVP-Ansatz für vorhandene Anwendungen nutzen können

Das Minimum Viable Product (MVP) hilft Ihnen in der Produktentwicklung, zentrale Annahmen früh zu überprüfen. Dabei gilt: besser früh und ...