Hier ist nochmal das Cumulative Flow Diagram aus der letzten Email:

In diesem Diagramm stecken Daten von den ersten 90 Tagen unseres Projekts. Damit können wir schon eine einfache Prognose machen: In 90 Tagen haben wir 17 Tickets geschafft, 30 sind es insgesamt, mittels Dreisatz kommen wir auf 159 Tage. Also sollten wir ungefähr am 10.6. fertig sein, oder?

Nicht ganz so schnell! Die Gesamtzahl an Tickets (oberste Grenze des Diagramms) ist ja bisher auch angewachsen, das müssen wir berücksichtigen. Solche Zuwächse können verschiedene Ursachen haben:

• Bugs
• Zerlegung von schon bekannten Backlog-Items in mehrere Tickets
• “Scope Creep”, d.h. neu hinzugekommene Wünsche

Es gibt ja keinen Grund, anzunehmen, dass dieser Zuwachs plötzlich aufhört. Also extrapolieren wir beide Linien, die Linie für Done und die Linie für die Gesamtzahl an Tickets. Das sieht dann so aus:

Es sind dieselben Daten wie oben, ich habe nur zwei Trendlinien hinzugefügt:

• Trend für “Done”, dafür verbinde ich einfach den ersten und den letzten Punkt auf der grünen Kurve (“Done”)
• Trend für die Gesamtzahl an Tickets. Dafür ignoriere ich die Anlaufphase, d.h. die ersten 24 Tickets.

Da, wo sich beide Trendlinien schneiden, haben wir das Projekt voraussichtlich fertig, also ungefähr am 1. August.

Ich finde, diese Grafik ist ganz gut geeignet, um den Fertigstellungstermin mit Stakeholdern zu diskutieren. Das beginnt mit Fragen wie: “Bedeutet ‘Done’ wirklich, dass wir das so ausliefern können?” und geht weiter mit “Warum wächst die blaue Linie eigentlich?” und “Bleibt die Kapazität des Teams in den nächsten Monaten gleich, so dass wir die grüne Linie einfach fortschreiben können?”

Oft wird der so vorhergesagte Termin “zu spät” sein, d.h. wir sollten z.B. schon am 1. Juli liefern. Wir haben nun zwei Bereiche, in denen wir gegensteuern können:

1. Die grüne Linie (Done) beschleunigen. “Schneller Arbeiten” wird eher nicht gehen. Aber wir könnten Feedback-Zyklen verkürzen, z.B. indem sofort nach der Phase “Dev” der ensprechende Test für das Ticket gemacht wird. Dann ist der Entwickler noch mit dem Ticket vertraut und kann Fehler schnell beheben. Allgemein kann man Feedbackbeschleunigen, indem man WIP (work in process) begrenzt. Dazu gehört hier auch die Empfehlung, die “Abnahme” (Übergang Testing -> Done) häufiger bzw. kontinuierlich zu machen.

2. Die blaue Linie, d.h. Zufluss an neuer Arbeit abbremsen. Bei Scope Creep kann man neu aufkommende Wünsche gegen vorhandene austauschen. Die drastischere Maßnahme wäre: Einen Feature Stop ausrufen, ab heute gibt es keine neuen Wünsche mehr. Das ist nicht sehr agil, kann aber helfen.

   Eine weitere Quelle von unvorhergesehener Arbeit sind Bugs, die nicht in der Testphase entdeckt wurden. Wenn man die Standard-Mittel zur Qualitätsverbesserung (Unit Tests, Code Reviews) einführen bzw. ausweiten will, braucht das etwas Anlaufzeit. Um ganz schnell etwas zu verbessern, kann man auch hier die Feedback-Zyklen verkürzen (WIP begrenzen).

Der einfachste und zuverlässigste Weg, um einen Termin zu halten, ist immer noch: Scope verringern. Dazu muss man nichts am Prozess ändern.

Wie weit können wir den Termin in unserem Beispiel vorziehen? Wir könnten sagen: wir liefern nur die 25 Tickets, die wir heute (Anfang April) im Entwicklungsprozess bzw. abgeschlossen haben (rote Linie). Wenn nichts Neues hinzukommt, können wir ungefähr Mitte Mai alles fertig haben – die grüne Trendlinie ist dann auf Höhe 25 angekommen.

Matthias Berth