Aufwandsschätzungen sind bei Ihnen oft ein Ratespiel? Julian Mayer und Stephan Ahrweiler listen die fünf häufigsten Probleme bei agilen Aufwandsschätzungen auf – und verraten die passenden Lösungen. Zusätzlich zeigen die Autoren, wie Sie mit User Stories Silos in Ihrem Unternehmen auflösen können.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Aufwandsschätzungen sind bei Ihnen oft ein Ratespiel? Julian Mayer und Stephan Ahrweiler listen die fünf häufigsten Probleme bei agilen Aufwandsschätzungen auf – und verraten die passenden Lösungen. Zusätzlich zeigen die Autoren, wie Sie mit User Stories Silos in Ihrem Unternehmen auflösen können.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Seit Beginn der Softwareentwicklung und der Veröffentlichung des agilen Manifests 2001 findet die agile Bewegung immer mehr Anhänger. Das iterative Projektvorgehen, bei dem aus vorangegangenen Perioden gelernt wird, soll schnellere und kundenzentrierte Entwicklungszyklen ermöglichen. Laut einer Studie von McKinsey und der University of Oxford überschreitet jedoch ein Softwareentwicklungsprojekt (>15 Mio. USD) – trotz agiler Arbeitsweisen – das Budget um durchschnittlich 66% und den zeitlich definierten Projektrahmen um 33%. Bei den etwa 5400 untersuchten IT-Projekten wurde eine Überschreitung des geplanten Gesamtbudgets von insgesamt 66 Mrd. USD ermittelt. Dieser Wert ist höher als das luxemburgische Bruttoinlandsprodukt.
Gemäß dem "digitalen Darwinismus" überleben nur die Unternehmen, die es schaffen, sich schnell und effizient an technologische Veränderungen anzupassen. Werden Softwareprojekte zukünftig nicht effizienter geplant und durchgeführt, kann ein Unternehmen dadurch die Wettbewerbsfähigkeit verlieren.
Die Ursachen hierfür sind vielfältig: Unrealistische Projektdimensionierung, größere ungeplante Entwicklungsprobleme, fehlende Ressourcen und Kompetenzen, Missmanagement oder die mangelhafte Ausführung agiler Methoden sind nur einige der möglichen Gründe. Letzteres stellt gerade in großen, bereichsübergreifenden agilen Projekten einen nicht zu vernachlässigenden Problemfaktor dar.
Bei vielen agilen Frameworks ist das Schätzen von Aufwänden ein integraler Bestandteil der iterativen Planung. Die Frameworks helfen, eine hohe Anzahl agiler Teams im Unternehmen zu koordinieren. Dabei setzen die Teams Aufgabenpakete, sog. Backlog Items, in zweiwöchigen Zyklen (Sprints) um. Um diese Sprints zu planen, benötigt es Schätzungen über den voraussichtlichen Arbeitsaufwand der einzelnen Backlog Items. In unserem Fall verwendeten wir User Stories als Backlog Items. Als übergreifendes Organisations- und Verwaltungstool werden häufig Tools wie Jira (Atlassian) verwendet. Dort werden alle Backlog Items inklusive Aufwandsschätzungen der einzelnen Teams digital erfasst.
Zur Schätzung von Aufwänden in agilen Teams gibt es verschiedene Methoden. Zwei sehr weit verbreitete sind das Estimation Game und Planning Poker. Bei beiden wird nicht in absoluten Einheiten, wie z.B. Personenstunden oder -tagen geschätzt, sondern in relativen Einheiten. Hierbei werden lediglich die Relationen zwischen den einzelnen Backlog Items betrachtet. Damit dies gelingt, muss das Team zunächst eine Referenzgröße definieren bzw. ein einheitliches Verständnis über relative Größen schaffen.
Der Vorteil der beiden Methoden ist die geringe Komplexität der Schätzung, da keine exakten zeitlichen Werte festgelegt werden müssen. Zudem wird keine Scheingenauigkeit suggeriert, da Aufgabenumfänge häufig nicht stundengenau bezifferbar sind. Beim Estimation Game werden gerne T-Shirt-Größen oder Tierarten als Größeneinheit verwendet. Eine User Story der Größe M ist z.B. größer als eine Story der Größe S, jedoch kleiner als eine der Größe L. In der Regel formuliert der Product Owner (PO) die User Stories und spezifiziert die Anforderungen an das zu entwickelnde Inkrement. Die Aufwandsschätzung erfolgt im Team (i. d. R. Product Owner, Scrum Master, Entwicklungsteam), wobei lediglich die Personen schätzen sollten, die die User Stories schlussendlich umsetzen. Während der Schätzrunden werden alle User Stories diskutiert und geschätzt.
Studien zufolge liegt die durchschnittliche Abweichung von geschätzten und tatsächlichen Aufwänden bei 20% bis 30% (Schweighöfer, 2016). Darüber hinaus werden 26% der Aufgaben erst während oder nach dem eigentlichen Sprint identifiziert (Grapenthin, 2014). Diese enormen Differenzen zeigen, warum gerade große Softwareentwicklungsprojekte, mit mehreren tausend Backlog Items pro Jahr, den finanziellen und zeitlichen Rahmen häufig sprengen.
Die Qualität einer Aufwandsschätzung ist abhängig von Kompetenz und Erfahrung der Teammitglieder und dem Austausch sowohl im Team als auch teamübergreifend. Außerdem spielt die disziplinierte und korrekte Anwendung der Methodik eine maßgebliche Rolle. In den meisten Fällen werden agile Aufwandsschätzungen nicht systematisch nach dem Lean-Gedanken optimiert, der u.a. SAFe (Scaled Agile Framework) zugrunde liegt. Der digital archivierte Datenschatz in Form von Backlog Items wird meist nicht genutzt, um den Planungsprozess bzw. das Planungsergebnis zu optimieren und aus vorherigen Sprints zu lernen.
Im Rahmen einer Projektstudie für einen führenden Automobilkonzern untersuchten wir, welche Probleme und Hindernisse bei agilen Aufwandsschätzungen auftreten und wie diesen auf Basis bestehender Daten und mittels Einsatzes von Technologie begegnet werden kann. Über 100 agil arbeitende Teams schätzten und archivierten zum Zeitpunkt der Untersuchungen jeweils mehrere hundert Backlog Items pro Jahr. Aus der Studie ergaben sich folgende fünf Hauptoptimierungspotenziale (Bild 1):
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
Keine spezifisch agilen Probleme
07.02.2020
Ich denke, dass die genannten Probleme nicht spezifisch für agile Aufwandsschätzungen sind, sondern für alle Arten von Schätzungen gelten.
Schätzungen sind ja auch ohne die aufgeführten Probleme noch schwierig. Ein agiles Vorgehen hat anschließend aber den Vorteil, dass Fehler in den Schätzungen schnell aufgedeckt werden, so dass das Team frühzeitig die Möglichkeit hat, seine initial möglicherweise fehlerhaften Vorhersagen zur Fertigstellung anzupassen.
Sind Schätzungen zur Planung und Budget sinnvoll?
14.02.2020
Vielleicht muss man auch einmal die Konsequenz ziehen, dass eine derartige Vorgehensweise, also frühzeitiges Schätzen, wenn die Unsicherheiten in einem Projekt am Größten sind um daraus ein Projektbudget zu errechnen einfach nicht funktioniert. Siehe z.B. auch "Cone of Uncertainty"; die Erkenntnisse sind schon Jahrzehnte alt.
Es gibt dazu andere Ideen wie beispielsweise Beyond Budgeting. Und eine iterative und vor allem inkrementelle Entwicklung sollte es eigentlich recht leicht machen, mein Budget sinnvoll zu investieren um den bestmöglichen Wert für mein Produkt heraus zu holen.
Aber sie erwähnen in Ihrem Beitrag die Automobilbranche. Ich kann aus eigener Erfahrung sehr gut nachvollziehen, dass lieber viel Zeit und Geld in die Perfektionierung alter Gewohnheiten gesteckt wird, als neue Methoden auszuprobieren.
Fokus etwas eng - auf Entwicklungsaufwände
25.09.2020
Die Schwäche agiler Methoden ist oft, dass man den Herausforderungen von Projekten, die in eine vorhandene, komplexe Legacy-Landschaft hineinarbeiten nicht gerecht wird. Planning Poker für ein solches Großprojekt ist nicht die Antwort.
Der Hinweis auf Beyond Budgeting im Kommentar von Steffen Thols möchte ich auch sehr unterstützen. Der unrealistische Wunsch nach guten Aufwandschätzungen in frühen Phase ist oft sehr drückend und von Finanzbereichen etc. getrieben.