Unternehmensweiter Wissenstransfer durch User Stories 5 Probleme bei agilen Aufwandsschätzungen

5 Probleme bei agilen Aufwandsschätzungen

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.

Management Summary

Unternehmensweiter Wissenstransfer durch User Stories 5 Probleme bei agilen Aufwandsschätzungen

5 Probleme bei agilen Aufwandsschätzungen

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.

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.

Warum überschreiten so viele IT-Projekte Budget und Projektrahmen?

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.

Die Schätzmethoden Team Estimation Game und Planning Poker

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.

Die Vorteile von Team Estimation Game und Planning Poker ...

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.

… und die Nachteile

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):

Die fünf häufigsten Probleme bei agilen Aufwandsschätzungen
Bild 1: Die fünf häufigsten Probleme bei agilen Aufwandsschätzungen

Die 5 häufigsten Fehler bei agilen Aufwandsschätzungen

1. Geringe Qualität der Backlog Items

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 5
Kommentare 2

Das könnte Sie auch interessieren

Alle Kommentare (2)

Rainer
Lingmann

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.

Steffen
Thols

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.