Aufwandsschätzung mal anders
Eine frische Perspektive zu Aufwandsschätzungen in der Softwareentwicklung
In der agilen Welt der Softwareentwicklung sind Teams oft damit konfrontiert, den erforderlichen Arbeitsaufwand für die Entwicklung neuer Features zu schätzen. Diese Schätzungen dienen als Fundament für die Planung von Sprints. Allerdings zeigt die Erfahrung, dass die tatsächlichen Aufwände regelmäßig von den ursprünglichen Schätzungen abweichen – und das meist nach oben. Einige Aufgaben werden aufgrund von Naivität oder dem Druck, niedrige Schätzungen abzugeben, unterschätzt, was zu einem Missverhältnis zwischen Schätzung und tatsächlichem Aufwand führt. Auch die schrittweise Erweiterung des Projekts als Reaktion auf neue Anforderungen oder aufkommende Schwierigkeiten kann zu einem Anstieg des Arbeitsaufwands führen. Und natürlich kann die technische Umsetzung unvorhergesehene Probleme und Schwierigkeiten mit sich bringen, die den ursprünglichen Schätzungen nicht zugrunde lagen.
Kurzum: Die Ursachen sind vielschichtig und reflektieren die Komplexität und Unberechenbarkeit von Softwareprojekten.¹
Neben der Ungenauigkeit der Schätzungen erzeugt der Schätzprozess selbst, wie beispielsweise durch das Bewerten mit Story Points, teilweise erheblichen zusätzlichen Aufwand, der nicht vernachlässigt werden sollte.
Was können Organisationen also tun, die sich mit dem Thema Aufwandsschätzung in der Softwareentwicklung beschäftigen?
Der Ansatz ohne Schätzen
Eine denkbare Lösung für diese Problematik ist der sogenannte #noestimates-Ansatz. Dabei verzichtet man auf die Schätzung von Arbeitspaketen in Story Points und zerlegt stattdessen Aufgaben in gleich große Teilaufgaben, deren Anzahl direkt erfasst werden kann. Die Gesamtzahl dieser Teilaufgaben dient dann als Maß für den Arbeitsaufwand. Ein angenehmer Nebeneffekt ist, dass Teams dadurch lernen, komplexe Aufgaben in überschaubare Einheiten zu gliedern und zu verstehen.
Doch ist das die Lösung?
Aufwandsschätzung – wozu?
Warum stecken wir überhaupt Aufwand in Aufwandsschätzungen? Die häufigsten Gründe sind:
Sprintplanung: Die Idee, Aufgaben basierend auf Story-Point-Schätzungen für den Sprintumfang zu definieren und sich zu verpflichten, diese zu erfüllen, erscheint mir fragwürdig. Ich bin überzeugt, dass ein effizientes Team ohnehin alles daran setzt, das Maximum zu erreichen. Sollte dies nicht gelingen, gibt es triftige Gründe, die nicht einfach dadurch gelöst werden können, dass man sich im Voraus verpflichtet, einen bestimmten Umfang zu erfüllen. Generell ist der Wert einer solchen Verpflichtung gering, wenn die meisten Schätzungen sowieso nicht eingehalten werden. Es ist unnötig, Energie darauf zu verwenden, so zu tun, als ob dies machbar wäre.
Optimierung der Geschwindigkeit (Velocity): Ein weiteres Argument für Aufwandsschätzungen ist die Messung und Optimierung der Teamproduktivität. Obwohl ein Team schnell entwickeln kann, können Abhängigkeiten oder erst spät erkannte Komplexitäten dazu führen, dass der Gesamtaufwand (oder die Dauer) erheblich steigt und der geplante Umfang nicht erreicht wird. Um die Produktivität zu messen, gibt es einfachere Methoden und Tools, die Produktivitätsmetriken direkt aus Versionsverwaltungs- (z. B. GitHub) oder Task-Management-Daten (z. B. Jira) automatisch ermitteln.
Wann sind welche Aufwandsschätzungen tatsächlich sinnvoll?
Sind Aufwandsschätzungen also völlig überflüssig? Keineswegs! Es gibt einen stichhaltigen Grund für ihre Durchführung: die Priorisierung und Planung von Projekten.
In der Produktentwicklung ist es notwendig, verschiedene Vorhaben zu priorisieren. Dies ist fast immer der Fall, da es typischerweise zahlreiche Ideen, Feature-Anfragen und lange Backlogs gibt, aber nur begrenzte Ressourcen für die Umsetzung. Für eine effektive Planung ist es wichtig, mehrere Aspekte zu vergleichen: den erwarteten Nutzen und den notwendigen Aufwand.
Für eine erfolgreiche Planung sind zudem Informationen über benötigte Abhängigkeiten für die Umsetzung des Projektes entscheidend, wie zum Beispiel der Zeitpunkt, zu dem ein anderes Team eine bestimmte Leistung erbringen muss.
Aufwandsschätzungen sind also essenziell für die Priorisierung und Planung von Projekten, allerdings nicht auf Sprintebene, sondern vor allem für die grobe Einschätzung des Aufwands für Meilensteine und die Gesamtumsetzung.
Wie kann man diese Aufwände einfach abschätzen?
Pragmatische T-Shirt-Größen
Eine praktikable Methode für Aufwandsschätzungen ist die Verwendung von T-Shirt-Größen. Dabei nutzt man Größen wie S, M und L, um den Aufwand grob zu klassifizieren. Vorab definiert man, was die Größen bezüglich des Aufwands bedeuten, zum Beispiel:
- S: 1-2 Team-Wochen
- M: 3-6 Team-Wochen
- L: 7-12 Team-Wochen
Bei Bedarf kann dieses System um Größen wie XS oder XL erweitert werden, jedoch sollte man hier nicht übertreiben, um nicht den Eindruck einer Genauigkeit zu erwecken, die in Wirklichkeit nicht gegeben ist.
Mit einer solchen Definition kann ein Team sehr schnell Vorhaben abschätzen.
Transparenz bei Unsicherheiten
Besonders bei der Planung von Projekten kann eine möglichst genaue Zeitangabe erforderlich sein. Agile Methoden weisen zu Recht darauf hin, dass eine präzise Vorhersage des Aufwands schwierig ist – besonders bei großen und weit in der Zukunft liegenden Projekten. Diese Unsicherheiten sollten in den Schätzungen berücksichtigt werden, indem man Zeiträume anstelle konkreter Dauern angibt, die die potenziellen Unwägbarkeiten widerspiegeln. Ein Beispiel wäre eine geschätzte Umsetzungsdauer für ein Projekt von 2 bis 6 Monaten. Und bei entsprechender Unsicherheit sollte die Bandbreite ruhig so hoch sein.
Schlussfolgerung
Aufwandsschätzungen auf Sprintebene sind wenig zielführend. Es gibt auch effektivere Methoden zur Optimierung der Teamgeschwindigkeit.
Wichtig und sinnvoll sind Aufwandsschätzungen jedoch für die Priorisierung von Gesamtprojekten, die mit minimalem Aufwand durch T-Shirt-Größen erfolgen können. Für die detaillierte Zeitplanung großer Projekte ist es ratsam, die Unsicherheit von Schätzungen durch die Angabe von Zeitbereichen transparent zu machen.
Der #noestimates-Ansatz bleibt hingegen ein wertvoller Ansatz im Sprint, da er sicherstellt, dass alle Aufgaben auf eine vergleichbare Größe heruntergebrochen und somit besser verstanden werden.
Extra-Bonus
Hier finden Sie 3 zusätzliche Fragen zu Aufwandsschätzungen, die Jan Hegewald beantwortet (bitte auf Plus drücken):
Was geschieht mit Arbeitspaketen, die kleiner als die kleinste T-Shirt Size sind?
Jan Hegewald: Natürlich könnte man auch die T-Shirt-Größen XS oder sogar XXS einführen. Hier stellt sich jedoch die Frage, ob es nicht effizienter wäre, das Arbeitspaket direkt umzusetzen, anstatt Zeit mit einer Aufwandsschätzung zu verschwenden. Die Antwort hängt davon ab, wofür diese Schätzung benötigt wird. Wenn Sie ein größeres Projekt schätzen, um es zu priorisieren, und das Arbeitspaket ist eines von vielen, dann würde ich empfehlen, das Arbeitspaket nicht kleinteilig aufzuschlüsseln und es stattdessen zusammen mit einem anderen Arbeitspaket zu schätzen.
Wie sinnvoll ist es, den Umfang von T-Shirt-Sizes in Beziehung zur vereinbarten Projektdauer zu setzen?
Jan Hegewald: Es gibt sicherlich Projekte mit harten Zeitanforderungen, z. B. bei der Umsetzung regulatorischer Vorgaben; aus meiner Sicht kann man aber eine ungefähre Projektdauer erst aus einer Aufwandsschätzung sinnvoll ableiten. Und da die Aufwandsschätzung zur ungefähren Projektdauer führt, ergibt es auch keinen Sinn, den Umfang der T-Shirt-Größen irgendwie anzupassen.
Die Aufwandsschätzung kann aber auf anderem Wege helfen, eine vom Markt vorgegebene Deadline zu treffen. Beispiel: Ein Projekt darf nur eine Woche dauern, die Summe der Arbeitspakete ergeben aber eine längere Projektdauer. Was könnte man tun? Entweder den Umfang reduzieren oder mehr Mitarbeitende in das Projekt aufnehmen. Doch Vorsicht: Doppelt so viele Personen ergeben nie die halbe Zeit. Erstens steigt mit der Anzahl der Personen in einer Gruppe der Kommunikationsaufwand exponentiell und zweitens lassen sich viele Aufgaben nicht beliebig parallelisieren.
Wie sinnvoll ist es, T-Shirt-Size-Planungen miteinander zu vergleichen?
Jan Hegewald: Ich halte es für sinnvoll, die T-Shirt-Size-Planungen miteinander zu vergleichen. Wenn Sie die Planungen als Grundlage für die Priorisierung verwenden wollen, sollten alle Projekte den gleichen Aufwandsbereich haben – z. B. wie oben beschrieben “S” mit 1-2 Teamwochen, “M” mit 3-6 Teamwochen, etc. So ist es möglich, bei zwei Vorhaben mit ähnlichem Nutzen, aber unterschiedlichem Aufwand, die “billigere” Variante zu wählen.
Übrigens: Story Points eignen sich aus meiner Sicht nicht als projektübergreifende Priorisierungsgrundlage.
Hinweise:
[1] Der Artikel “Why are software development task estimations regulary off by a factor of 2-3?” beschreibt die Diskrepanz zwischen Aufwandsschätzung und Aufwand sehr anschaulich.
Jan Hegewald bloggt unter https://www.agil-gefuehrt.de über moderne Führung und Agilität. Und auf https://www.jan-hegewald.de finden Sie weitere Inhalten zu Themen rund um digitale Produktentwicklung. Auf LinkedIn können Sie leicht mit ihm Kontakt aufnehmen.
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Jan Hegewald hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:
Die agile Migration von Anwendungen
Conways Einbahnstraße
Jan Hegewald
Jan Hegewald ist VP Engineering bei SumUp Ltd. in Berlin. Zuvor war er Director of Engineering für die Product and Category Experience bei Zalando SE und als Head of Technology B2B bei der idealo internet GmbH tätig.
Davor hat er lange Zeit für große Unternehmen individuelle IT-Systeme für kritische Kernprozesse konzipiert, gebaut und eingeführt. Außerdem beriet er unterschiedlichste Kunden zu Projekt-, Programm- und Portfolio-Managementmethodiken jeweils mit Sicht auf Prozesse, Organisation, Tools und persönliche Kompetenzen der Mitarbeiter.