“Wie hoch ist der Aufwand?”, “Mit welcher Dauer müssen wir rechnen?” – typische Fragen im Projekt Business und Product Development. Im agilen Management ist das Ziel (“Was”) immer klar definiert, der Weg dorthin (“Wie”) jedoch unklar. Um den Aufwand für diesen unbekannten Weg zu bestimmen, helfen agile Schätzungen. Welche Vorteile agile Schätzmethoden im Vergleich zu klassischen Aufwandsschätzungen wie Personentagen haben, erklären wir hier.

Personentage nicht mehr zeitgemäß

In komplexen Umgebungen komplexe Aufgaben zu managen ist nicht ohne. Was dabei jedenfalls nicht hilfreich ist, sind präzise Antworten zu Umfang und Dauer. Deshalb haben viele gelernt, komplexe Aufwandsschätzung von der tatsächlichen Umsetzung bzw. der Entwickler-Geschwindigkeit zu entkoppeln. Wie? Mit der agilen Regel # 7:

Umfang und Dauer trennen

Man schätzt also nicht konkret, sondern abstrakt – am besten mit Größen aus dem Alltag wie einem T-Shirt. Beim T-Shirt-Sizing werden Kundenwünsche (meist als Epics formuliert) in Kleidergrößen von S bis XXL geschätzt, um ein Gespür für kleine und wirklich große Dinge zu bekommen. Nicht selten wird diese Technik in der Praxis aber missbraucht, indem man sich eine Matrix zurechtlegt die in etwa so aussieht: S = 3 PT, M = 5 PT usw.

Personentage = Dauer != Aufwand

Personentage stehen aber für klassische Schätzungen, weil klassische Aufwandsschätzungen sich mit Zeiteinheiten in h, d oder PT befassen, welche nicht für komplexe Umgebungen geeignet sind! Der Grund: je komplexer die Aufgaben sind, desto schwerer wird es vorherzusehen, wie viele Zeiteinheiten 1 Person für 1 Task benötigt. Zuviel Unvorhergesehenes  tritt auf und verzögert ggf. die Entwicklung: Abhängigkeiten zu anderen Teams und Abteilungen, Unterbrechungen durch andere Aufgaben, alte technische Schulden werden beglichen, div. Code Quality Issues, der täglich unterschiedliche Mood der DEVs usw.

Schätzung von Geschwindigkeit entkoppeln

Story Points stehen für agile Schätzungen, um Umsetzungsaufwände zeitgemäß zu schätzen. In agilen Projekten gibt es immer 2 Konstanten: Zeit + Budget. Das einzige was flexibel bzw. agil ist, ist der Umfang. Der Umfang ist das Ziel – und das Ziel dabei ist immer, möglichst viel von den richtigen Anforderungen umzusetzen. Es gilt deshalb den Weg zum Ziel zu schätzen und nicht den Aufwand.

Der Weg ist das Ziel

Ein Beispiel: Wir reisen für einen Kunden von Linz nach Innsbruck und wissen die ungefähre Entfernung (Anzahl der Kilometer). Wie wissen auch, wie wir dort hinkommen können: mit dem Auto, dem Zug oder dem Flugzeug. Die Entfernung bleibt in etwa die gleiche, aber die Zeit variiert je nach der Art und Weise der Reise, plus ein paar Unsicherheiten wie Wetter, Verkehrslage und Zeitpunkt.

Aufwands- statt Zeit-Einheiten

Es gilt also den Weg (km) zu schätzen und den damit verbundenen Aufwand (Distanz) von der Geschwindigkeit (v) zu entkoppeln. Es gilt den zurückzulegenden Weg zu schätzen und nicht den Piloten (ein Senior Dev mit Jet ist schneller am Ziel als ein Junior Dev mit Skateboard;). Die fixe Arbeitsmenge (= der zu erledigende Task mit seinem Gesamtaufwand an Entwicklung + Test + weitere Aktivitäten) bleibt die gleiche, die flexible Umsetzungsdauer wird aber dadurch entkoppelt.

Schätzen Sie deshalb immer den Weg – aber nicht das Zurücklegen diesen Weges!