Ein effizientes Verfahren zur Abschätzung des Umfangs im agilen Umfeld

Zusammenfassung

Für Projektbeteiligte, die eine frühzeitige, nachvollziehbare Abschätzung über den Umfang eines Projekts benötigen, ist Rapid Estimation ein effizientes Verfahren, an dessen Ende ein vollständig abgeschätztes Backlog steht.
Im Vergleich zum üblichen klassischen Schätzverfahren hebt sich Rapid Estimation ab, weil es verschiedene agile Methodiken zu einem ganzheitlichen Verfahren vereint.

Motivation

Die Abschätzung von Aufwänden ist häufig sehr aufwendig und damit mit hohen Kosten verbunden. Dem gegenüber steht leider zu oft nur ein geringer Wert. Die Abschätzung erweist sich als wenig verlässlich und die Planung ist nur von geringen Nutzen für die Umsetzung.

Mit Rapid Estimation versuche ich ein effizientes Verfahren zu schaffen, in dem der Aufwand und der Nutzen einer Aufwandsabschätzung in einem optimalen Verhältnis zueinander stehen.

Vorteile

Durch das Verfahren entstehen sowohl die Grundlage, als auch wichtige Werkzeug für die Umsetzung in einem agilen Verfahren.

1. Herstellen eines gemeinsamen Verständnis. Die Anforderungen und die geplante Umsetzung sind in hohen Maß transparent.
2. Ein abgeschätztes Product Backlog, mit dessen Hilfe direkt gearbeitet werden kann.
3. Mit der User Story Map ein visuelles Werkzeug, dass auch während der Umsetzung dabei hilft Anforderungen weiter zu formulieren, und die Übersicht zu behalten.

Nachteile

Die Nachteile sind eigentlich keine echten Nachteile. Es sind eher Punkte, die man Bedenken und klar benennen sollte, damit das Verfahren gelingen kann, und keine falschen Erwartungen und Hoffnungen entstehen.

1. Rapid Estimation kann zu Beginn noch keine belastbare Aussage über die tatsächlichen Kosten und Laufzeit bei der Umsetzung machen. Das Ergebnis ist eine erste sehr grobe Schätzung. Eine genauere Prognose wird erst nach einer gewissen Zeit möglich, wenn sich zeigt, wie schnell das Team Anforderungen umsetzen kann. Dann sind diese Aussagen aber sehr verlässlich. Das Aushalten dieser anfänglichen Unsicherheit ist eine Herausforderung.
2. Damit Rapid Estimation funktioniert, ist die Mitarbeit aller Projektbeteiligten schon zu Beginn des Projekts erforderlich! Leider ist zu diesem Zeitpunkt häufig noch nicht klar, wer wirklich an dem Projekt beteiligt sein wird. Es kann also schwierig werden, diese Gruppe an Personen zusammen zu stellen.

Vorgehen

Es wird nun Schritt für Schritt das Rapid Estimation Verfahren beschrieben. Dabei werden bewährte Verfahren und Vorgehen aus dem agilen Umfeld angewendet. Auf diese wird nur sehr oberflächlich eingegangen. Für ein weitergehende Information zu den Vorteilen und Anwendung dieser Methoden wird auf die reichhaltige Literatur und Dokumentation zu diesen Methoden verwiesen.

1. Ermittlung und Visualisierung der Anforderung

Die Ermittlung der Anforderung wird gemeinsam mit allen Projektbeteiligen durchgeführt. Es ist wichtig, dass in diesem Schritt alle Beteiligten involviert sind, damit ein gemeinsames Verständnis entstehen kann. Bei einem Vorgehen nach Scrum sind das die Stakeholder, der Product Owner und insbesondere das Entwicklungsteam, da dieses später die Schätzung durchführen wird.

Die Visualisierung der Anforderung geschieht durch eine User Story Map. User Story Mapping ist ein Verfahren von Jeff Patton, mit dessen Hilfe die Anforderung in Form einer Geschichte visuell erzählt werden kann.

Das Erzählen einer Geschichte fördert Lücken und unterschiedliche Sichtweisen zuverlässig zu Tage, so dass diese diskutiert werden können. Ein gemeinsames Verständnis ist die Basis für eine belastbare Schätzung! Das Fehlen dieses Verständnis ist der Hauptgrund für das Scheitern von Planung und Umsetzung. Deswegen lege ich im ersten Schritt sehr großen Wert darauf, die Anforderungen in einer Form aufzubereiten, in der dieses Verständnis entstehen kann. Geschichten fördern das mehr als jedes andere Mittel. Die intuitive Darstellung einer User Story Map fördert eine fokussierte und zielgerichtete Diskussion. Perfekt!

Eine User Story Maps ist in zwei Dimensionen aufgeteilt. Das Backbone ist ein Erzählstrang, auf dem von links nach rechts, in chronologischer Reihenfolge, Aktionen (Epics) beschrieben sind, die ein Nutzer in der Lösung durchführt bzw. durchführen kann. Die Aktionen lassen sich nach oben weiter zu Themen zusammenfassen und abstrahieren, um die Übersicht zu verbessern. Unterhalb jeder Aktion finden sich die dazugehörigen User Stories. Diese beschreiben mögliche Optionen einer Aktion in detaillierterer Form.

Beim Erstellen dieser Map entsteht das gemeinsame Verständnis nahezu automatisch. Es wird diskutiert, in welcher Reihenfolge Aktionen durchgeführt werden sollen. Es werden Aktionen voneinander abgegrenzt, aufgeteilt und zusammengeführt, aufgenommen und entfernt. Es wird ermittelt, welche User Stories wirklich wichtig oder optional sind. Es entstehen so verschiedene Handlungsoptionen, die bewertet werden können. Es empfiehlt sich die Prioritäten nach dem angenommenen Geschäftswert an die Themen, Aktionen, und User Stories zu schreiben. Bei der Reihenfolge sollten man sich zunächst auf die Themen und Aktionen konzentrieren, die einen hohen Geschäftswert haben.

Die Map muss nicht bis in das letzte Detail ausgestaltet werden, sondern darf eine relativ große Unschärfe haben. Aber sie muss mit Blick auf eine Spätere Schätzung vollständig auf den jeweiligen Ebenen sein. Es dürfen keine relevanten Punkte wissentlich ausgelassen werden und Lücken entstehen. Das würde die Transparenz verletzen.

Die Map muss grundsätzlich alle Themen abdecken. Für mindestens eines der Themen müssen die Aktionen bestimmt werden. Die Aktionen eines Themas müssen in sich vollständig sein. Für mindestens eine Aktion müssen die User Stories beschreiben werden. Auch hier gilt: Die Users Stories einer Aktion müssen vollständig sein.
Um eine ausreichende Grundlage an User Stories für die Schätzung zu haben, sollten sich aus der Map am Ende mindestens 15 User Stories auslesen lassen. Je mehr User Stories in die Schätzung einfließen umso besser.

2. Schätzen

Im nächsten Schritt wird der Umfang der User Stories relativ zueinander geschätzt. Die Schätzung mit relativen Werten ist von elementarer Bedeutung in diesem Verfahren. Die wichtigsten Gründe hierfür sind:

1. Menschen können besser relativ als absolut schätzen.
2. Relative Schätzungen führen auch dann zu guten Ergebnissen, wenn noch wenig über die konkrete Lösung bekannt ist.
3. Relative Schätzungen führen auch in Gruppen mit unterschiedlichen Wissen und Können zu einem Konsens.

Die Schätzung findet auf der Basis der Fibonacci-Reihe statt. Diese bildet die Unsicherheit einer Schätzung von größeren Elementen dadurch ab, indem die Abstände zwischen zwei Zahlen bei höheren Werten größer werden.

Zur Schätzung können Verfahren wie das Planning Poker oder andere Verfahren verwendet werden. Bei sehr großen Mengen an User Stories empfehle ich Magic Estimation oder Team Estimation. Die Ergebnisse der Schätzung werden an den entsprechenden User Stories notiert.

3. Reverse Estimation

Im nächsten Schritt wird die initiale Schätzung, auf die gesamte User Story Map extrapoliert. Dazu gehen wir Bottom-Up von den Userstories aus vor. Ich nenne dieses Verfahren daher auch Reverse Estimation.

Während der Reverse Estimation entstehen zwei verschiedene Werte für die Größen der einzelnen User Stories und Epics etc:

1. Exakte Werte (blau markierte Werte im Schaubild), die wir später für die Einträge im Backlog verwenden. Diese bestimmen den Gesamtumfang des Backlogs.
2. Nach der Fibunacci-Reihe aufgerundete Werte (Werte in den Klammern im Schaubild). Diese verwenden wir nur für weitere relative Schätzungen. Sie haben keine Bedeutung für das Backlog.

Im ersten Schritt summieren wir zunächst die Schätzungen der User Stories einer Aktion. Die Summe (16) wird an die jeweilige Aktion übertragen. Für die weitere relative Schätzung runden wir diese Summe auf die nächst größere Zahl in der Fibonacci-Reihe (20). Auch diese schreiben wir auf die Karte der Aktion. Auf diese Weise erhalten die einzelnen Aktionen im Backbone einen Schätzwert.

Im zweiten Schritt werden die Schätzungen der Aktionen vervollständigt. Hierzu werden die Aktionen wieder relativ zueinander abgeschätzt. Dabei benutzen wir die gerundeten Werte. Danach werden die exakten Schätzwerte eines Themas (16, 13, 13) erneut summiert und an das jeweilige Thema übertragen (42). Für die weitere Schätzung runden wir diesen Wert erneut und auf die nächst größere Zahl in der Fibonacci-Reihe (55).

Im letzten Schritt wird analog wie schon bei den User Stories und Aktionen verfahren. Die Summe aller exakten Werte über alle Themen stellt den geschätzten Gesamtumfang unser Anforderung da.

4. Erstellung des Backlog

Ein großer Vorteil dieses Verfahrens ist, dass auf der Basis des User Story Mapping und der Schätzung ein vollständiges Backlog erstellt werden kann, in dem grundsätzlich der Gesamtumfang (167) nthalten ist.

In das Backlog werden initial folgende Elemente mit ihren exakten Schätzwerten aufgenommen:

1. Alle Users Stories
2. Aktionen, für die es keine User Stories gibt
3. Themen für die es keine Aktionen gibt

Das Backlog kann nun nach den Prioritäten sortiert werden. Im Idealfall erhält der Product Owner ein Backlog, in dem die hoch priorisierten Stories oben stehen und direkt durch das Team bearbeitet werden können.

Eine erste grobe Schätzung zur Laufzeit und Kosten der Umsetzung ergibt sich unmittelbar aus der ersten Sprintplanung des Development Teams. Wenn sich das Team vornimmt Userstories im Umfang von 20 Punkten umzusetzen, lässt sich über den Gesamtumfang des Backlogs leicht die Anzahl der voraussichtlich notwendigen Sprints, und damit die Kosten und Laufzeit schließen. Die Schätzung ist aber zu Beginn sehr grob und wird sich verändern, sobald klarer wird, wie schnell das Team Anforderungen umsetzen kann.