Agile Schätzungstechniken

Abstract

Die Schätzung des Arbeitsaufwands in agilen Projekten unterscheidet sich grundlegend von den traditionellen Schätzungsmethoden. Der traditionelle Ansatz ist die Schätzung mit einer „Bottom-up“-Technik: Man beschreibt alle Anforderungen im Detail und schätzt jede Aufgabe zur Erfüllung dieser Anforderungen in Stunden/Tagen, dann verwendet man diese Daten zur Entwicklung des Projektplans. Agile Projekte hingegen verwenden einen „Top-Down“-Ansatz, bei dem Schätztechniken auf Grobebene für Feature-Sets verwendet werden und dann progressive Ausarbeitungs- und Rolling-Wave-Planungsmethoden eingesetzt werden, um auf Just-in-Time-Basis bis zur Aufgabenebene vorzudringen, wobei iterativ auf jeder Ebene mehr und mehr Details aufgedeckt werden. In diesem Beitrag werden zwei gängige Techniken für die agile Schätzung (Planungspoker und Affinitätsgruppierung) näher erläutert und es wird darauf eingegangen, wie die Ergebnisse dieser Übungen in die Zeit- und Budgetprognose einfließen.

Top-down vs. Bottom-up

Die herkömmliche Methode für die Schätzung von Projekten besteht darin, zu Beginn eines Projekts mehrere Wochen oder Monate damit zu verbringen, die detaillierten Anforderungen für das zu erstellende Produkt zu definieren. Sobald alle bekannten Anforderungen erfasst und dokumentiert sind, kann ein Gantt-Diagramm erstellt werden, das alle zur Erfüllung der Anforderungen erforderlichen Aufgaben sowie die Schätzung der einzelnen Aufgaben enthält. Die Ressourcen können dann den Aufgaben zugewiesen werden, und Aktionen wie Beladung und Nivellierung helfen bei der Bestimmung des endgültigen Liefertermins und Budgets. Dieser Prozess wird als Bottom-up-Methode bezeichnet, da alle Details des Produkts definiert werden müssen, bevor der Zeitplan und die Kosten des Projekts geschätzt werden können.

In der Softwarebranche hat die Verwendung der Bottom-up-Methode aufgrund der heutigen Änderungsgeschwindigkeit gravierende Nachteile. Die Geschwindigkeit des Wandels bedeutet, dass die Geschwindigkeit neuer Entwicklungstools und die Geschwindigkeit des Zugangs zu neuem Wissen so groß ist, dass jede Verzögerung bei der Lieferung dazu führt, dass man offen für konkurrierende Alternativen ist und Gefahr läuft, ein veraltetes Produkt zu liefern (Sliger, 2010).

Die Top-Down-Methode geht auf dieses Hauptproblem ein, indem sie die derzeit verfügbaren Informationen verwendet, um Schätzungen auf Bruttoebene zu erstellen. Die rollierende Planung wird dann verwendet, um neue Informationen einzubeziehen, sobald sie bekannt werden, um die Schätzungen weiter zu verfeinern und iterativ mit mehr Details auszuarbeiten, während das Projekt fortschreitet. Diese Methode, bei der gerade genug gelernt wird, um loszulegen, mit einem Plan, mehr Wissen zu integrieren, wenn sich die Arbeitsergebnisse entwickeln, ermöglicht es dem Projektteam, schnell auf Widrigkeiten und sich ändernde Marktnachfrage zu reagieren.

Schätztechniken

Schätztechniken auf Bruttoebene werden von Teams verwendet, die agile Ansätze wie Scrum und Extreme Programming verwenden, und in diesem Papier werden zwei der beliebtesten Techniken behandelt: Planning Poker und Affinity Grouping. Die verwendeten Schätzungseinheiten werden ebenfalls untersucht, da diese Einheiten so beschaffen sein sollten, dass sie nicht mit der Zeit verwechselt werden können.

Planungspoker

Die beliebteste Technik der Schätzung auf Bruttoebene ist das Planungspoker oder die Verwendung der Fibonacci-Folge, um einem Merkmal oder Element einen Punktwert zuzuweisen (Grenning, 2002). Die Fibonacci-Folge ist eine mathematische Zahlenreihe, die im 13. Jahrhundert eingeführt wurde und zur Erklärung bestimmter prägender Aspekte der Natur, wie der Verzweigung von Bäumen, verwendet wird. Die Reihe entsteht durch die Addition der beiden vorhergehenden Zahlen, um den nächsten Wert in der Reihe zu erhalten: 0, 1, 1, 2, 3, 5, 8, 13, 21, und so weiter. Für die Zwecke der agilen Schätzung wurden einige der Zahlen geändert, was zu der folgenden Reihe führt: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Diese Zahlen werden in einem Satz von Spielkarten dargestellt (siehe Abbildung 1). Die Teammitglieder spielen „Planungspoker“ (Anlage 2), um für jeden Posten eine Schätzung in Form eines Punktwertes abzugeben. Hier sind die Schritte:

• Jedes Teammitglied erhält einen Satz Karten.
• Der Geschäftsinhaber (der NICHT schätzen darf) stellt den zu schätzenden Posten vor.
• Der Posten wird besprochen.
• Jedes Teammitglied wählt privat eine Karte aus, die seine Schätzung darstellt.
• Wenn alle bereit sind, werden alle ausgewählten Karten gleichzeitig aufgedeckt.
• Wenn alle Teammitglieder die gleiche Karte ausgewählt haben, dann ist dieser Punktwert die Schätzung.
• Wenn die Karten nicht gleich sind, diskutiert das Team die Schätzung, wobei der Schwerpunkt auf den abweichenden Werten liegt:
  • Das Mitglied, das den niedrigsten Wert gewählt hat, erklärt, warum er/sie diesen Wert gewählt hat.
  • Das Mitglied, das den höchsten Wert gewählt hat, erklärt, warum er/sie diesen Wert gewählt hat.
• Wählen Sie erneut, bis die Schätzungen konvergieren.
• Sollte es zu langwierigen oder unübersichtlichen Gesprächen kommen, können die Teammitglieder einen Zwei-Minuten-Timer verwenden, um die Diskussion in eine Zeitspanne einzuteilen, und jedes Mal, wenn der Timer abgelaufen ist, erneut auswählen, bis eine Konvergenz erreicht ist.
• Wiederholen Sie dies für jeden Punkt (Cohn, 2006, S. 56-57).

Es gibt mehrere Gründe, warum Fibonacci-Zahlen verwendet werden, und zwar in diesem Format. Der erste Grund ist, dass die Teams, sobald sie die Zeit als Basis für die Schätzung eliminieren, weniger dazu neigen, mehr Details zu verlangen und die Schätzungen aufzublähen. Diese Zahlen stellen stattdessen die relative Größe dar, nicht die Zeit. Infolgedessen geht die Schätzung recht schnell vonstatten. In der Regel verbringen die Teams etwa zwei Minuten mit jedem Element, so dass ein Rückstand von 30 Elementen in einer Stunde geschätzt werden kann. Die Tatsache, dass die Teams nur 9 Auswahlmöglichkeiten (d. h. Punktwerte oder Karten) haben, trägt ebenfalls zur Beschleunigung des Prozesses bei.

Die Abfolge bietet auch den richtigen Detaillierungsgrad für kleinere und besser verständliche Merkmale, während sie bei höheren Schätzungen ein falsches Gefühl von Genauigkeit vermeidet. Ein Element mit einer hohen Schätzung (20 oder höher) bedeutet zum Beispiel, dass das Element groß und noch nicht gut verstanden ist. Eine Diskussion darüber, ob es sich um eine 20, 19 oder 22 handelt, wäre reine Zeitverschwendung, da einfach nicht genügend Daten zur Verfügung stehen. Sobald die Aufgabe näher an die Iteration heranrückt, in der sie bearbeitet werden soll, kann sie in kleinere Teile zerlegt und in feineren Zahlen (1-13) geschätzt werden. Aufgaben mit Punktschätzungen von 1-13 können im Allgemeinen innerhalb einer einzigen Iteration (1-4 Wochen) abgeschlossen werden.

Es ist wichtig zu beachten, dass Punkte nicht in allen Teams die gleiche Bedeutung haben; zum Beispiel ist die „Fünf“ eines Teams nicht gleich der „Fünf“ eines anderen Teams. Daher sollte die aus Punkten abgeleitete Teamgeschwindigkeit nicht zum Vergleich der Produktivität verschiedener Teams herangezogen werden.

Affinitätsgruppierung

Eine noch schnellere Methode zur Schätzung, die bei einer großen Anzahl von zu schätzenden Elementen eingesetzt wird, ist die Affinitätsgruppierung. Die Teammitglieder gruppieren einfach Elemente gleicher Größe zusammen, was zu einer Konfiguration ähnlich der in Abbildung 3 führt. Die Methode ist einfach und schnell:

• Der erste Gegenstand wird den Teammitgliedern vorgelesen und an der Wand platziert.
• Der zweite Gegenstand wird vorgelesen und das Team wird gefragt, ob er kleiner oder größer als der erste Gegenstand ist; die Platzierung an der Wand entspricht der Antwort des Teams (größer ist rechts, kleiner ist links).
• Der dritte Gegenstand wird vorgelesen und das Team wird gefragt, ob er kleiner oder größer als der erste und/oder zweite Gegenstand ist; der Gegenstand wird entsprechend an der Wand platziert.
• Die Kontrolle wird dann an das Team übergeben, um die Affinitätsgruppierung für die restlichen Gegenstände abzuschließen.

Die Teams können auf dieselbe Weise fortfahren, indem sie nach der Gruppendiskussion einen Gegenstand nach dem anderen an der Wand platzieren. Schneller geht es jedoch, wenn jedes Teammitglied einen Gegenstand auswählt und ihn nach bestem Wissen und Gewissen anbringt. Dabei arbeiten alle Teammitglieder parallel, bis alle Gegenstände bewertet und an der Wand angebracht wurden. Mehrere hundert Gegenstände können in relativ kurzer Zeit geschätzt werden. Sobald alle Gegenstände an der Wand angebracht sind, überprüft das Team die Gruppierungen. Elemente, die nach Ansicht eines Teammitglieds in der falschen Gruppe sind, werden besprochen und gegebenenfalls verschoben.

Wenn die Affinitätsgruppierung abgeschlossen ist, können Werte für Schätzungseinheiten wie Punkte zugewiesen werden. In Abbildung 3 würde die erste Gruppe ganz links einen Wert von 1 Punkt haben, die zweite Gruppe 2 Punkte, die dritte Gruppe 3 Punkte, die vierte Gruppe 5 Punkte und die letzte Gruppe 8 Punkte.

Affinitätsgruppierungen können auch für andere Schätzungseinheiten wie T-Shirt-Größen vorgenommen werden. Abbildung 4 zeigt ein Beispiel für affinitätsgruppierte Elemente, die mit T-Shirt-Größen anstelle von Punkten gekennzeichnet sind.

Schätzungseinheiten

Die Verwendung von T-Shirt-Größen (Extra Small , Small , Medium , Large , Extra Large ) ist eine weitere Möglichkeit, relative Größen von Merkmalen zu betrachten. Dies ist eine noch größere Abweichung vom numerischen System, und wie alle guten Schätzungseinheiten auf Bruttoebene können sie in keiner Weise mit einer bestimmten Zeitspanne in Verbindung gebracht werden.

Andere willkürliche Maßeinheiten sind Gummibärchen, NUTS (Nebulous Units of Time) und Fuß-Pfund. Teams können ihre eigenen Schätzungseinheiten schaffen, und wie Sie sehen können, haben sie oft ein bisschen Spaß dabei.

Dieses Papier behandelt nicht die Verwendung von zeitbasierten Einheiten wie ideale Entwicklungstage und/oder -stunden. Diese sind bereits weit verbreitet und werden gut verstanden, so dass ihre Erklärungen nicht aufgenommen wurden. Es ist jedoch erwähnenswert, dass eine Schätzung auf Bruttobasis erfolgreicher sein kann, wenn sie vom Begriff der Zeit abgekoppelt wird. Da Zeitschätzungen von der Geschäftsleitung und dem Unternehmen oft in Verpflichtungen umgewandelt werden, fühlen sich die Teammitglieder stärker unter Druck gesetzt, so genau wie möglich zu sein. Infolgedessen verlangen sie immer mehr Details über den zu schätzenden Gegenstand. Dadurch wird die Schätzung auf Bruttoebene zu einer zeitaufwändigeren Schätzung auf Detailebene und der ursprüngliche Sinn und Zweck wird verfehlt.

Prognose von Zeitplan und Budget

Sobald die Schätzungen auf Bruttoebene und die Teamgeschwindigkeit bestimmt sind, können Zeitplan und Budget prognostiziert werden. Teams bestimmen ihre Velocity, indem sie die Gesamtzahl der Punkte für alle Elemente addieren, die sie in einer Iteration abgeschlossen haben. So kann ein Team beispielsweise fünf Elemente mit einem Gesamtpunktwert von 23 Punkten ausgewählt haben (siehe Abbildung 5). Am Ende der zweiwöchigen Iteration konnte das Team nur vier der fünf Punkte abschließen. Ihre Geschwindigkeit beträgt 15 Punkte, d. h. die Summe der Punktwerte der Aufgaben 1-4. Teams erhalten keine „Teilpunkte“ für das Abschließen von Teilen eines Items, d. h. selbst wenn sie mit Item 5 begonnen hätten, würde es nicht zählen, da es nicht abgeschlossen wurde.

Bestimmung des Zeitplans

Die durchschnittliche Geschwindigkeit eines Teams wird für die Prognose eines langfristigen Zeitplans verwendet. Die durchschnittliche Geschwindigkeit wird berechnet, indem die Geschwindigkeitsmessungen der letzten drei Iterationen des Teams addiert und diese Summe durch drei geteilt wird. Wenn also ein Team in seiner ersten Iteration 15 Punkte und in den beiden folgenden Iterationen jeweils 20 Punkte erreicht hat, beträgt die durchschnittliche Geschwindigkeit des Teams 18 (15+20+20 / 3). Wenn ein Team in einer Iteration durchschnittlich 18 Punkte erreichen kann und in dem Projekt 144 Punkte zu erledigen sind, benötigt das Team acht Iterationen, um die Arbeit abzuschließen (144 / 18). Wenn jede Iteration zwei Wochen dauert, dann beträgt die voraussichtliche Fertigstellung 16 Wochen. Mit dieser Methode lässt sich die Frage beantworten: „Wann werden wir mit der ganzen Arbeit fertig sein?“

Wenn das Team über eine Aufzeichnung von Geschwindigkeitsdaten verfügt, kann es das optimistischste, das pessimistischste und das wahrscheinlichste Fertigstellungsdatum ermitteln. Zur Berechnung des wahrscheinlichsten Szenarios wird die durchschnittliche Velocity-Zahl des Teams verwendet, während zur Berechnung des pessimistischsten prognostizierten Fertigstellungstermins die Velocity-Zahlen aus den Iterationen mit der schlechtesten Leistung des Teams herangezogen werden. Die Verwendung der Velocity-Zahlen aus Iterationen, in denen das Team mehr als erwartet abschließen konnte, liefert die optimistischste Prognose.

Wir können diese Zahlen auch verwenden, um die Frage zu beantworten: „Wir müssen bis zu diesem Datum etwas liefern – wie viele dieser Funktionen werden wir bis dahin fertiggestellt haben?“ In Abbildung 6 finden Sie ein Beispiel für die wahrscheinlichste Prognose der Fertigstellung, die pessimistische Prognose und die optimistische Prognose. Dieses Beispiel bezieht sich auf ein Team mit einer durchschnittlichen Geschwindigkeit von 20, einer Geschwindigkeit im schlechtesten Fall von 12 und einer Geschwindigkeit im besten Fall von 25. Wie viel kann unter diesen Voraussetzungen in nur sechs Wochen (drei Iterationen) abgeschlossen werden? Die pessimistische Prognose lautet, dass nur die Aufgaben 1-8 in sechs Wochen erledigt werden können. Die optimistische Prognose lautet, dass die Punkte 1-18 abgeschlossen werden können. Und die wahrscheinlichste Vorhersage, basierend auf der durchschnittlichen Geschwindigkeit des Teams von 20, ist, dass die Aufgaben 1-13 in sechs Wochen abgeschlossen werden.

Wenn Teams nicht-numerische Schätzeinheiten wie T-Shirt-Größen verwenden, werden die Algorithmen für die Vorhersage komplexer. Es wird empfohlen, die Größen in ein numerisches System umzuwandeln, um leichter ähnliche Daten zu erzeugen. So könnte beispielsweise eine kleine Größe in eine NUT von 3, eine mittlere Größe in eine NUT von 5 usw. umgewandelt werden. Diese können auch in Zeitspannen umgewandelt werden (eine Small könnte z.B. 1-3 Tage betragen), aber dies ist aufgrund der bereits im Abschnitt „Schätzungseinheiten“ genannten Probleme mit einem gewissen Risiko verbunden.

Bestimmung des Budgets

In diesem Abschnitt geht es um die Beantwortung der Frage: „Wir haben nur so viel Geld – wie lange wird es reichen und wie viel werden wir geschafft haben, bevor es aufgebraucht ist?“ Zunächst wird eine einfache Formel verwendet, um die Kosten pro Punkt zu ermitteln:

Σ (aufgeladene Teamgehälter für Zeitraum n) / in Zeitraum n abgeschlossene Punkte

Nehmen Sie die Summe der (aufgeladenen) Teamgehälter für einen bestimmten Zeitraum, z. B. drei zweiwöchige Iterationen, und teilen Sie diese durch die Anzahl der Punkte, die das Team in diesem Zeitraum abgeschlossen hat. Ein Team, das über einen Zeitraum von sechs Wochen insgesamt 240.000 $ verdient und in diesen drei Iterationen 60 Arbeitspunkte erledigt hat, hat also Kosten pro Punkt von 4.000 $. Verwenden Sie nun die folgende Formel, um das Budget zu bestimmen:

(Kosten pro Punkt x Gesamtpunktwert der abzuschließenden Punkte) + sonstige Ausgaben = prognostiziertes Budget

Häufig sind zu Beginn eines Projekts nicht alle Funktionen für ein Produkt definiert, was bei agilen Projekten zu erwarten ist. Daher basieren die Budgetschätzungen auf dem, was wir heute wissen, plus einem Prognosealgorithmus, der auf historischen Daten oder Expertenempfehlungen beruht. Nehmen wir zum Beispiel an, dass bisher nur 20 Funktionen aufgelistet sind, das Unternehmen aber keine zusätzlichen Funktionswünsche oder Verfeinerungen einbringen kann, bevor es nicht gesehen hat, wie die erste Version beim Kunden ankommt. Im Budget für das Projekt, das für drei Versionen vorgesehen ist, wären nur Prognosedaten für die erste Version und nicht für das gesamte Projekt verfügbar. Das Team könnte den obigen Algorithmus verwenden, um das Budget für die erste Version zu prognostizieren und dann für die zweite Version zusätzliche 20 % und für die letzte Version zusätzliche 5 % auf der Grundlage früherer Erfahrungen annehmen.

Wie die Geschwindigkeit werden auch die Budget- und Zeitplanprognosen in jeder Iteration überarbeitet. Dies ist Teil des Rolling-Wave-Planungsprozesses, dem agile Projekte unterliegen.

Abschließende Worte

Das Fehlen strukturierter Schätztechniken, wie sie in Lean-Ansätzen wie Kanban verwendet werden, wird in diesem Papier nicht behandelt. Anstatt Zeit mit der Schätzung von Artikeln zu verbringen (zu verschwenden), werden die durchschnittlichen Zyklus- und Durchlaufzeiten auf der Grundlage der tatsächlichen Durchsatzraten des Teams berechnet. Kanban verwendet das mathematische Theorem Little’s Law als Grundlage für seine Formeln. Mithilfe von Durchlaufzeitberechnungen, die aus kumulativen Flussdiagrammen abgeleitet werden, können Teams Projektzeitpläne prognostizieren, ohne im Vorfeld Zeit für die Erstellung von Schätzungen aufwenden zu müssen. Der Leser wird ermutigt, eigenständig zu diesem Thema zu recherchieren, was eine eigene Abhandlung sein könnte.

Agile Projekte zielen darauf ab, ein Produkt oder Produktinkremente früh und oft zu liefern, um Kundenfeedback und andere Erkenntnisse in die nächste Version einfließen zu lassen. Indem mehr Zeit auf das Experimentieren, Ausführen und Lernen und weniger Zeit auf Spekulationen verwendet wird, verkürzt sich die Zeit für die Lieferung. Agile Teams sind besser in der Lage, auf dem Markt zu konkurrieren und mit dem immer schneller werdenden Wandel Schritt zu halten.