Kein Aufwand für Aufwandschätzungen

Die Illusion der Präzision: Ein kritischer Blick auf Aufwandschätzungen in der Softwareentwicklung

Herausforderungen beim Schätzen

In der Welt der agilen Softwareentwicklung stehen Teams regelmäßig vor der Aufgabe, den Aufwand für Feature-Entwicklungen zu schätzen. Diese Aufwandschätzungen sollen als Grundlage zum Beispiel für die Sprintplanung dienen. Doch die realen Aufwände weichen fast immer deutlich von den Schätzungen ab. Und zwar ebenfalls fast immer: nach oben. Dieser Artikel aus dem Jahr 2015 erläutert sehr anschaulich, warum das in der Softwareentwicklung ein typisches Phänomen ist.

Reale Aufwände weichen fast immer deutlich von ihren Schätzungen ab. Und zwar ebenfalls fast immer: nach oben.

Die Gründe hierfür sind vielfältig und spiegeln die Komplexität und Unvorhersehbarkeit von Softwareprojekten wider. Zusätzlich zu den ungenauen Schätzungen verursacht der Prozess des Schätzens selbst – beispielsweise durch das Bewerten von Story Points – einen nicht zu unterschätzenden Aufwand.

Der #noestimates-Ansatz

Als mögliche Lösung für dieses Dilemma wird der #noestimates-Ansatz diskutiert. Hierbei wird darauf verzichtet, Arbeitspakete in Story Points zu schätzen. Stattdessen werden Aufgaben in gleich große Tasks heruntergebrochen, die ohne weitere Schätzungen gezählt werden können. Die Summe dieser Tasks dient dann als Aufwandschätzung. Ein positiver Nebeneffekt: Ein geübtes Team stellt so sicher, dass auch komplexe Tasks in handhabbare Aufgaben heruntergebrochen und damit auch verstanden werden.

Löst das also das Problem? Um das zu beantworten stellt sich zunächst die Frage, wozu Aufwandschätzungen überhaupt dienen sollen.

Der Zweck von Aufwandschätzungen

Als Gründe für Aufwandschätzungen werden meist folgende Zwecke angeführt:

• Sprintplanung: „Wir definieren anhand von Story-Point-Schätzungen diese Aufgaben als Umfang des Sprints und verpflichten uns dazu diese zu liefern.“ Das halte ich für unnütz. Meine Überzeugung ist, dass ein funktionierendes Team ohnehin sein Bestes geben wird um so viel wie möglich zu erreichen. Wenn das nicht klappt, wird es gute Gründe dafür geben, die sich nicht auflösen, indem man vorher „schwört“ den Umfang zu schaffen. Generell liegt wenig Wert in der Verpflichtung auf einen Umfang, wenn die meisten Schätzungen ohnehin nicht zutreffen. Dann braucht man keine Energie darauf zu verschwenden so zu tun, als ob das ginge.
• Velocity-Optimierung: Ein häufig vorgebrachtes Argument für Aufwandschätzungen ist, dass nur mit diesen die Teamproduktivität (Velocity) gemessen und optimiert werden könne. Ein Team kann schnell entwickeln, aber Probleme mit Abhängigkeiten oder spät entdeckte Komplexität führen dennoch dazu, dass der Gesamtaufwand (oder die Dauer!) deutlich steigen und trotz womöglich hoher Entwicklungsgeschwindigkeit des Teams der Umfang im Sprint nicht geschafft wird.
  Um die Produktivität zu messen, gibt es einfachere Wege, wie zum Beispiel Tools, die Produktivitätsmetriken allein anhand von Versionsverwaltungs- (GitHub) oder Task-Management- (Jira) Daten automatisiert erheben (z. B. CodeClimate Velocity). Auch hierfür brauche ich keine zusätzliche Aufwandschätzung vorab.

Hinweis: Natürlich sieht es anders aus, wenn ich im Projektgeschäft tätig bin und meine Leistung zu einem Festpreis verkaufen muss. Diesen Fall lasse ich hier außen vor.

Wozu Aufwandschätzungen wirklich gut sind

Braucht man also gar keine Aufwandschätzung? Doch! Es gibt einen validen Grund für Aufwandschätzungen.

• Vorhabenpriorisierung und -Planung: In der Produktentwicklung müssen verschiedene Vorhaben priorisiert werden. Das ist praktisch immer der Fall, denn typischerweise gibt es Unmengen von Ideen, Feature-Wünschen und ellenlange Backlogs, aber nur sehr begrenzte Umsetzungskapazitäten. Dafür müssen mehrere Aspekte der Vorhaben verglichen werden: Der erwartete Nutzen der Vorhaben, aber auch der dafür nötige Aufwand.
  Für eine gute Planung sind außerdem Informationen darüber wichtig, wann welche Abhängigkeiten für die Umsetzung des Vorhabens benötigt werden, z. B.: Wann muss ein anderes Team eine bestimmte Zulieferung fertig haben, damit das Vorhaben umgesetzt werden kann?

Aufwandschätzungen sind also wichtig für die Priorisierung und die Planung von Vorhaben. Aber nicht auf Sprints heruntergebrochen, sondern vor allem der grobe (!) Aufwand für Meilensteine und um das Gesamtvorhaben umzusetzen. Wie kann ich diese Aufwände einfach schätzen?

Aufwandschätzungen sind nur wichtig für Priorisierung und Planung von Vorhaben.

Einfachheit durch T-Shirt-Größen

Für eine pragmatische Aufwandschätzung bieten sich Schätzungen mit T-Shirt-Größen an. Dabei werden Größen, wie S, M und L, genutzt, um den Aufwand grob zu klassifizieren. Vorab legt man fest, was die Größen an Aufwand bedeuten sollen, z. B.:

• S: 1-2 Team-Wochen
• M: 3-6 Team-Wochen
• L: 7-12 Team-Wochen

Bei Bedarf kann man dieses System noch um XS, XL etc. erweitern. Man sollte es aber nicht übertreiben. Die Gefahr ist hoch, dass man damit wiederum eine Scheinpräzision suggeriert, die gar nicht real ist.

Eine Einschätzung nach T-Shirt-Größen lässt sich in der Regel sehr schnell in einem Team abstimmen. Je größer das Vorhaben allerdings ist, desto eher muss dafür ein technisches Lösungs-Design vorliegen.

Alternative: Unsicherheit transparent machen

Insbesondere für die Planung von Vorhaben kann es sein, dass eine möglichst präzise Zeitdauer für Vorhaben oder Meilensteine gefordert wird. Das ist auch valide, wenn es um die bestmögliche Planung von großen Vorhaben mit vielen komplexen Abhängigkeiten geht.
Natürlich haben agile Methoden aber recht mit der Feststellung, dass wir Aufwände vorab schlecht schätzen können – umso schlechter, je größer und weiter in der Zukunft die Aufwände liegen. Diese Unsicherheiten können – und sollten – wir in Schätzungen widerspiegeln. Es empfiehlt sich anstatt präziser Dauern Bereiche zu schätzen, die die Unwägbarkeiten abbilden, z. B. eine Umsetzungsdauer von 1-3 Monaten. Dieser Bereich kann entsprechend der Unsicherheit durchaus groß sein, wie im Beispiel die Bandbreite von 300% zwischen dem besten und schlechtesten Fall.

Wir können Aufwände schlecht schätzen – umso schlechter, je größer und weiter in der Zukunft die Aufwände liegen.

Fazit

Aufwandschätzungen auf Sprint-Ebene sind meiner Auffassung nach Zeitverschwendung. Um Velocity zu optimieren, gibt es einfachere Wege. Nützlich und nötig sind Aufwandschätzungen von Vorhaben für deren Priorisierung. Die kann man mittels T-Shirt-Größen mit minimalem Aufwand schätzen. Sind detailliertere Zeitschätzungen nötig um große Vorhaben mit vielen Abhängigkeiten zu planen, sollte man die Unsicherheit einer Schätzung transparent machen, indem man einen Zeitbereich anstelle einer konkreten Dauer angibt. Der #noestimates-Ansatz ist dennoch sehr hilfreich. Er stellt sicher, dass alle Aufgaben in einem Sprint auf eine vergleichbare Größe heruntergebrochen sind und dadurch gut verstanden.

Wie stehst du zu Aufwandschätzungen und welche Erfahrungen hast du damit gemacht?