Story Points vs Time Units

“Wie hoch ist der Aufwand?”, “Mit welcher Dauer müssen wir rechnen?” – alltägliche Fragen im Projekt Business und im Produkt Development. Ist agiles Leadership in komplexen Umgebungen vorhanden, ist zumindest das Ziel (Was?) klar definiert, der Weg dorthin (Wie?) aber noch unklar. Agile Schätzungen helfen den Aufwand für diesen Weg zu bestimmen. Eine kurze Erklärung warum Personentage nicht mehr zeitgemäß sind und die Aufwandsschätzung von der Entwickler-Geschwindigkeit entkoppelt werden soll.

Agile Regel #7: trenne Umfang von Dauer

In agilen Umgebung schätzt man nicht konkret, sondern abstrakt – zB mit Größen die man vom Alltag kennt wie T-Shirts. Beim T-Shirt-Sizing werden Kundenwünsche (meist als Epics formuliert) in Kleidergrößen von S bis XXL geschätzt. Damit bekommt man ein Gespür für kleine und wirklich große Dinge. Nicht selten wird diese Technik in der Praxis aber missbraucht, indem sich eine Matrix zurechtlegt wir, die in etwa so aussieht: S = 3 PT, M = 5 PT usw.

Personentage = Dauer != Aufwand

Mit Personentagen führt man aber erst recht wieder klassische Schätzungen ein. Alle klassischen Aufwandsschätzungen die sich mit Zeiteinheiten in h, d oder PT befassen, eignen sich nicht für komplexe Umgebungen! Je komplexer die Aufgaben, desto schwerer wird es vorherzusehen, wie viele Zeiteinheiten 1 Person für 1 Task benötigt – es gibt immer Abhängigkeiten, Unterbrechungen, technische Schulden, Code Quality Issues, Mood der DEVs uvm. die nicht vorhersehbar sind.

Deshalb: Schätzung von Geschwindigkeit entkoppeln!

Story Points sind ein gutes Beispiel um Umsetzungsaufwände agil zu schätzen. In agilen Projektumgebungen gibt es immer 2 Konstanten: die Zeit + das Budget. Das einzige was flexibel bzw. agil ist, ist der Umfang. Egal ob in Iterationen gearbeitet wird oder nicht: das Ziel ist möglichst viel von den richtigen Anforderungen umzusetzen.

Nehmen wir an, wir reisen für einen Kunden von Linz nach Innsbruck. Wir wissen die ungefähre Entfernung, also die Anzahl der Kilometer. Wie wissen auch, wie wir dort hinkommen können, nämlich mit dem Auto, dem Zug oder dem Flugzeug. Die Entfernung bleibt in etwa gleich, aber die Zeit variiert je nach der Art und Weise wie ich Reise, hinzu kommen noch ein paar unsichere Faktoren wie Wetter und Verkehrslage.

Exkurs: Unterbrechungen – Beispiele

schlechte Infrastruktur (langsame Hardware, langsame Netzwerkverbindung, zu kleine Bildschirme, zu wenig Zugriffsrechte auf relevante Systeme), ineffiziente Kommunikation, schlechte Verfügbarkeit des POs (mindestens 50% der verfügbaren Arbeitszeit/Vollzeit), unnötiger Druck, schlechte Qualität, Mehraufwand, Frustration, Konflikte

Ergo: Einheiten für Aufwand statt für Zeit verwenden

Es gilt also den Weg (die Kilometer) zu schätzen und den damit verbundenen Aufwand (die Entfernung) von der Geschwindigkeit zu entkoppeln. Wir wollen den zurückzulegenden Weg schätzen und nicht den Piloten (ein Senior Dev mit Jet wird eine Aufgabe schneller erledigen als ein Junior Dev mit Skateboard). Der zu erledigende Task mit seinem Gesamtaufwand (Entwicklung + Test + weitere Aktivitäten) und seine Arbeitsmenge bleiben die gleichen – die eigentliche (flexible) Umsetzungsdauer wird dadurch aber entkoppelt.

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