“Wie weit sind wir? Wann wird das Projekt fertig?” – das sind wichtige und legitime Fragen im Projektgeschäft. Normalerweise verlässt man sich bei der Antwort auf Schätzungen für den Arbeitsaufwand (“Wir brauchen noch 4 Monate”). Die #NoEstimates-Bewegung argumentiert nun, dass man dieselben Fragen besser ohne den Rückgriff auf Schätzungen beantworten sollte. Auf die Probleme mit Schätzungen will ich hier nicht eingehen, betrachten wir sie einfach als ein notwendiges Übel.

Der Name #NoEstimates ist aus meiner Sicht unglücklich gewählt. Mit dem propagierten Verzicht auf alle Arten von Schätzungen provoziert man gleich Abwehrreaktionen: “Wie, Ihr wollt nicht mehr schätzen? Dann sollen wir Euch wohl beliebig viel Zeit lassen, bis Ihr fertig werdet? Es dauert so lange wie es dauert, oder was?” Das ist nicht sehr hilfreich, vielleicht wird sich noch ein besserer Name finden (“Statistische Projekt-Vorhersage”?)

Ich habe kürzlich das Buch von Vasco Duarte (No Estimates - how to measure project progress without estimating) gelesen, in der Hoffnung auf ein bisschen mehr Klarheit zum Thema. Wenn man die Kontroversen um den Schlachtruf #NoEstimates ignoriert, bleibt ein im Kern sehr interessantes Konzept, das auf jeden Fall Denkanstöße gibt.

Die von #NoEstimates angebotene Alternative zu Schätzungen lautet:

Statt den Arbeitsaufwand zu schätzen, mache eine Vorhersage, wann das Projekt fertig sein wird. Benutze dafür historische Daten über bisher abgearbeitete Aufgaben.

Insbesondere werden User Stories eben nicht geschätzt (“Wir brauchen 2 ideale Arbeitstage für diese Story”), auch nicht mit Story Points. Die Metrik “Velocity” (abgearbeitete Story Points pro Iteration) wird damit auch obsolet. Es wird allein die Anzahl an Aufgaben verwendet–das spart natürlich eine Menge Zeit gegenüber der Schätzung.

So kommt man zu einer Vorhersage:

1. Beobachte Anfangs- und Fertigstellungs-Zeit einiger Aufgaben (z.B. user stories). Zähle nur wirklich fertige Aufgaben (“Done Done”).
2. Entwickle daraus ein statistisches Modell für die Abarbeitung. Bisher habe ich in diesem Schritt nur Monte-Carlo-Simulationen gesehen. Duarte ignoriert Statistik in seinem Buch völlig, wahrscheinlich um die Beschreibung einfach zu halten.
3. Wende das statistische Modell an, mit der Anzahl noch zu erledigender Aufgaben als Parameter.

Beispiel: Wir haben noch 100 User Stories abzuarbeiten. Bisher haben wir 15 User Stories abgearbeitet, deren Anfangs- und Enddaten geben wir in eine Black Box (Monte-Carlo-Simulation). Die Monte-Carlo-Simulation generiert 10000 simulierte Projektverläufe auf Grundlage der 15 Beobachtungen. Das Ergebnis ist eine Vorhersage wie: “Mit 90% Wahrscheinlichkeit werden wir die verbleibenden 100 Aufgaben in spätestens 303 Tagen fertig haben.” Das bedeutet, 90% der simulierten Projektverläufe waren 303 Tage oder kürzer.

Vorteile dieser Herangehensweise sind:

• Es wird ein Bereich für die Fertigstellung angegeben, statt eines erwarteten Termins. Das macht die Unsicherheit in der Vorhersage sichtbar. Es wird damit deutlich, dass dies eine Prognose ist und keine Selbstverpflichtung auf einen Termin.
• Es basiert auf beobachteten Daten, nicht auf subjektiven Einschätzungen. Damit entfällt der manchmal zu erlebende (meist unterschwellige) Druck, die Schätzungen an das erwartete Ergebnis anzupassen.

Damit so eine statistische Vorhersage funktioniert, braucht es einige Voraussetzungen:

Einen relativ unveränderten Gesamtprozess. Wenn z.B. auf halbem Wege die Team-Zusammensetzung oder die Entwicklungsmethodik geändert wird, dann beziehen sich die historischen Daten eigentlich auf einen anderen Prozess.

Keine (oder wenige) Ausreißer in der Durchlaufzeit. In der statistischen Prozesslenkung (Statistical Process Control) würde man sagen: “Der Prozess ist stabil”. Wenn hingegen manche Aufgaben eine extrem lange Durchlaufzeit von mehreren Monaten haben, werden diese Ausreißer die Prognose verderben.

Klein geschnittene Aufgaben. Daraus folgt auch: Aufgaben (user stories) müssen klein genug geschnitten sein. Das erfordert etwas Übung. Es ist aber vertretbar, wenn die Aufgaben sich im Arbeitsaufwand bis zu einem Faktor 10 unterscheiden. Uns reicht also die intuitive Aussage “Diese Aufgabe ist jetzt klein genug, wir müssen sie nicht weiter zerlegen”.

Kurze Durchlaufzeiten relativ zur Projektdauer. Wenn alle Features erst ganz am Ende des Projekts “fertig” sind, wird die Vorhersage nicht funktionieren. Aussagen wie: “Wir sind in Monat 3 und Feature X ist zu 50% fertig” sind auch nicht belastbar. Viele Datenpunkte zu kurzen Durchlaufzeiten liefern gute statistische Prognosen.

Anfangsdaten. D.h. Beobachtungen zur Durchlaufzeit von Stories für das betrachtete Team und das betrachtete Projekt. Je länger die Reihe der vorliegenden Daten, desto zuverlässiger ist normalerweise die Vorhersage.

Die Voraussetzungen passen gut zu Lean-Prinzipien: viele kleine Aufgaben fließen möglichst gleichmäßig durch den Prozess (Flow, Heijunka) und wir versuchen, die Durchlaufzeiten klein zu halten.

Ein Online-Tool zur Prognose auf Grundlage von fertiggestellten Aufgaben ist Projectr. Interessanterweise genügen schon die Anfangs- und Endezeiten für 15 einzelne Aufgaben, um eine Prognose zu machen (mehr Werte sind natürlich besser). Der Hintergrund-Artikel “Stop guessing, use data! (Or how we estimate at Lunar Logic)” ist auch sehr lesenswert. Schließlich möchte ich noch auf den recht ausgewogenen Beitrag “The #NoEstimates debate” zu Hintergrund und Protagonisten verweisen.

Matthias Berth