In diesem Beitrag beschäftigen wir uns mit Aufwandsschätzung in digitalen Projekten.

Egal, wie agil ein Projekt zu App-Entwicklung oder Umsetzung von Webanwendungen ist: Es benötigt immer eine Einschätzung, wie viel Input für einen bestimmten Output benötigt wird. Das Thema ist ja schließlich immer auch Rentabilität und Risikomanagement. 📊

Dennoch ist jedes agile Projekte mit vielen unbekannten Parametern belegt. Und das macht die Herausforderung aus. Denn: Kannst du in die Zukunft schauen?

Zwischen Agilität und ROI

Jedes Projekt hat seine Chancen und Risiken. Agile Projekte sind deshalb agil, weil nicht immer alle Anforderungen von vornherein klar sind oder sich verändern.

Agilität braucht weniger Planung, weil die Aufgaben und Leistungen innerhalb des Projektes nicht starr sind, sondern verändert werden können.

Das macht das Auflisten und endlose Anforderungsanalysen inklusive Gantt-Charts weitgehend überflüssig.

Dennoch braucht jeder Projektleiter eine Idee davon, was bei einem Projekt rauskommen wird. Und dabei muss er oder sie wissen, wie viel Aufwand für ein bestimmtes Ergebnis geleistet werden muss. 🤯

Deswegen ist Einschätzung ein wesentlicher Teil der Projektplanung und Kommunikation. Mit Einschätzung von Story Points und Value Points erhalten User Stories eine Quantifizierung und Wertigkeit, die sonst häufig nur diskutiert wird. 🗣

Die geschätzten Aufwände und der Wert einzelner Aufgaben, den die Projektteilnehmer schätzen, bekommen Zahlen. Diese sind aber nicht absolut, sondern relativ zueinander geschätzt.

Denn wir Menschen sind besser in der Schätzung relativer Zahlen als in der Schätzung absoluter Zahlen.

Wir wissen vielleicht nicht, ob die Entwicklung des Logins 2 oder 4 Wochen dauert. Aber wir können erahnen, dass der Login 4 mal mehr Aufwand bedarf, als die Integration eines Profil-Avatars.

Voraussetzung für agile Schätzungen

Um gemeinschaftlich effektiv zu schätzen, sollten wir die Grundlage dafür schaffen.

Wir gehen also davon aus, dass alle daran interessiert sind, frühzeitig Werte für den Kunden/Nutzer zu erzeugen, in dem man Aufgaben nach mit höherem Nutzen nach vorzieht.

✅ Wir vertrauen dem Team und seinen Schätzungen.

✅ Nur das Umsetzungsteam schätzt die Aufwände für die Aufgaben.

✅ Nur der Kunde oder der Nutzer, als entsprechender Auftraggeber bestimmen den Wert einer Aufgabe.

Jedes Team braucht Zeit sich einzuspielen und mit der Zeit erhalten wir verlässlichere Wertigkeiten. z. B. auch dafür wie viele Story Points in einem Sprint überhaupt angegangen werden können. Denn Zeit ist und war selten ein verlässliche Hausnummer für Aufwände in agilen Projekten.

Deswegen gibt es ja Story Points für die Einschätzung von Aufgaben im Sprintplanning. Aber das ist ein anderes Thema.

Wie schätzen wir agil?

Ganz kurz gesagt, nehmen wir uns die Liste der Aufgaben oder Funktionen, die wir mit dem Team definiert haben und die für das Projekt relevant sind.

Dann schätzen wir die Story Points. Wir wählen dafür die kleinste Aufgabe und die größte Aufgabe aus dieser Liste. Die kleinste legen wir in der vertikalen (Achse auf einer Skala) nach unten, die größte nach oben.

Dann verteilen wir dazwischen alle weiteren Aufgaben im Verhältnis zu dieser Benchmark von kleinstem zu größtem Aufwand. Die User Stories erhalten also eine Relation zu den beiden Extremen.

Das gleiche machen wir mit den Value Points. Wir werden also wieder alle Aufgaben durcheinander, setzen die (für den Kunden oder Nutzer) am wenigsten wertvolle Aufgabe nach unten und die wertvollste nach oben.

Alle weiteren verteilen wir je nach Einschätzung zwischen diesen beiden Ankergrößen. Dann nehmen wir die Relation aus Aufwand und Nutzen. Fertig!

User Story und Value Points zusammenbringen

Klar, ganz so einfach ist es vielleicht nicht. Was ist denn die Skala, die wir verwenden?

Dafür nutzen wir die Fibonacci-Folge: 1, 3, 5, 8, 13, 21, 34, 55, 89, 144, …

Die kleinste Aufgabe kann die 1 bekommen. Dir größte vielleicht die 144. Und die anderen Aufgaben werden dann innerhalb dieser Skala eingeordnet.

Gleiches gilt für die Value Points. Auch die erhalten einen Wert auf der Skala.

Womit wird jetzt gestartet?

Wir suchen jetzt das beste Preis-Leistung-Verhältnis. Beispiel: Schätzen wir für Funktion als User Story A eine Größe von 144 Story Points bei rund 13 Value Points und für Funktion mit der User Story B einen Umfang von 55 Story Points bei einem Wert von 89 Value Points, dann ergibt sich folgende Rechnung für den Value pro Story Point:

User Story A:
13 VP / 144 SP = 0.9

User Story B:
89 VP / 55 SP = 1.6

B bringt ein besseres Verhältnis und damit also pro Aufwandseinheit mehr Nutzen. Also starten wir mit B. Nachvollziehbar soweit.

Diese Verhältnisse werden für alle vorgeschlagenen Funktionen oder User Stories (je nachdem wie ihr arbeitet) errechnet. Dann werden die wertvollsten Stories vorangestellt.

Technische und strategischen Anforderungen

Jetzt gibt es natürlich Anforderungen, die erfüllt sein müssen. Es lässt sich kein Login entwickeln, wenn keine Infrastruktur da ist.

Gemeinsam mit den Stakeholdern und speziell das Team und der Kunde (des digitalen Produktes) definieren, ob einzelne Stories eine nicht verhandelbare oder notwendige Voraussetzung für alle weiteren Aufgaben sind.

Diese Aufgaben werden dann in Ihrer erforderlichen Reihenfolge vor den anderen User Stories sortiert. Wenn ich ein Haus baue, dann braucht es schließlich auch tragende Wände, bevor ich ein Dach aufsetzen kann.

Out of Scope

Diese Methode ist noch kein Allerheilmittel für ein gutes Sprintplanning. Dazu gehören viele, weitere Parameter. Dennoch gibt sie einen Ansatz, Diskussionen im Team und Einschätzungen in eine Struktur zu bringen und Wertigkeit zu definieren.

Ob eine Story dann wirklich Voraussetzung ist, kann dann von Ihrer Ausgestaltung oder ihren Anforderungen abhängen. Oder: Die Story wird Verhandlungssache zwischen Kunden und Team. Nicht immer ist die genannte Voraussetzung vielleicht keine allgemein im Team akzeptierte Voraussetzung.

Das ist und bleibt Verhandlungssache. Diskussionen werden dadurch nicht aufgelöst, glücklicherweise. Da kommt man dann bei der Zusammenarbeit verschiedener Organisationen auch gar nicht drum herum. Und das soll ja auch gar nicht das Ziel sein. Oder? Also: Happy Estimations everyone.

Wir können dich in deinem Digitalprojekt unterstützen? Mit einem Workshop oder als Team zur Umsetzung eurer Webanwendungen und Apps? Bucht auf unserer Seite direkt ein Erstgespräch.