Für eine erfolgreiche Projektplanung ist eine präzise Aufwandsschätzung essenziell. Unternehmen müssen den Ressourcenbedarf frühzeitig kennen, um realistische Angebote zu erstellen. In agilen Projekten stoßen traditionelle Schätzmethoden jedoch an ihre Grenzen. Unterschiedliche Arbeitstempi, wechselnde Anforderungen und die iterative Entwicklung erschweren exakte Prognosen. Statt fester Zeitangaben setzen agile Teams daher auf relative Komplexitätsschätzungen. Diese Methode ermöglicht eine flexiblere und realistischere Planung. Allerdings müssen diese Schätzungen sorgfältig durchdacht sein, da sie nicht nur die Angebotskalkulation, sondern auch die Sprintplanung beeinflussen. Fehlende Konsistenz in den Schätzungen kann zu Instabilität im Projektverlauf führen.
Zeitliche Schätzungen sind selten agil
Die meisten Menschen bewerten ihre Aufgaben in zeitlichen Dimensionen: Stunden, Tage etc. Sie stützen sich auf Erfahrungswerte. Dieser Ansatz ist einfach und leicht zu vermitteln. Eine Autowerkstatt weiß zum Beispiel genau, wie lange es dauert, einen Ölfilter für ein bestimmtes Fahrzeugmodell zu wechseln. Schließlich hat sie genau diesen Vorgang schon mehrfach durchgeführt.
Im agilen Umfeld sind solche Erfahrungswerte jedoch weniger hilfreich. Das liegt zum einen an der iterativen Natur agiler Projekte. Der Zyklus von Planung, Implementierung, Test und Review macht es schwierig, den endgültigen Aufwand für ein Arbeitspaket vorherzusagen. Außerdem werden agile Methoden in der Regel für komplexe Aufgaben eingesetzt, die grundsätzlich schwieriger zu schätzen sind.
Mechaniker können den Aufwand für einen Ölwechsel zeitlich genau vorhersagen. Schildert ein Kunde in der Werkstatt jedoch ein schleifendes Geräusch im Radkasten, das gelegentlich ab 120 km/h bei niedrigen Außentemperaturen auftritt, sieht die Sache anders aus. In diesem Fall kann der Mechaniker dem Kunden nicht genau sagen, wie lange die Reparatur dauern wird. Deshalb verzichten viele agile Teams auf Zeitschätzungen. Stattdessen nutzen sie die Komplexität der Aufgabe als entscheidendes Bewertungskriterium.
Komplexität statt Zeit schätzen
Menschen haben Schwierigkeiten, den genauen Aufwand für eine Aufgabe einzuschätzen, aber sie können gut einschätzen, ob eine Aufgabe komplexer als eine andere ist. Relationen zwischen Objekten hingegen sind ein bewährtes Vorgehen. Es ist unmöglich, die exakte Körpergröße eines Kollegen zu bestimmen. Man kann jedoch feststellen, dass die Körpergröße eines Kollegen größer ist als die eigene. Im agilen Projektmanagement ist die Komplexitätsschätzung das Mittel der Wahl, um die Relationierung von Aufgabenpaketen zu ermöglichen.
Auch wenn der tatsächliche Implementierungsaufwand einer Software-Funktion nicht bekannt ist, kann man ihre Komplexität im Vergleich zu einer bekannten Aufgabe ziemlich präzise einschätzen. Darauf aufbauend kann eine fundierte Beurteilung der Umsetzbarkeit einer Funktion innerhalb eines Sprints oder der Notwendigkeit einer Aufteilung vorgenommen werden. Ein signifikanter Vorteil von Komplexitätsschätzungen liegt in ihrer zeitlichen Unabhängigkeit. Die Umsetzungsdauer eines Aufgabenpakets kann variieren, abhängig von der Projektkomplexität und den Lerneffekten des Teams. Der Komplexitätsgrad steht jedoch weitestgehend fest. Das macht die Schätzung deutlich nachhaltiger.
User Stories als Grundlage
In agilen Projekten ist es üblich, Kundenanforderungen in User Stories zu unterteilen – kurze Beschreibungen einer Funktion aus Kundensicht, formuliert nach folgendem Muster:
Als [Rolle] möchte ich [Funktion], um [Nutzen].
User Stories bilden die Grundlage für die Aufgabenplanung im Rahmen eines Sprints, inklusive der Aufwandsschätzung. Dafür müssen sie jedoch einige Qualitätsanforderungen erfüllen. Hierzu hat sich die INVEST-Mnemonik von Bill Wake als Leitlinie etabliert:
- I – Independent (unabhängig)
Gute User Stories haben keine konzeptionellen Überschneidungen. Auf diese Weise kann das Projektteam sie flexibel planen und umsetzen. - N – Negotiable (verhandelbar)
Gute User Stories sind lösungsneutral formuliert. Dadurch fällt es Kunde und Anbieter leichter, die Details der Anforderung zu besprechen und gemeinsam den richtigen Ansatz zu finden. - V – Valuable (nützlich)
Gute User Stories stellen den Kundenutzen in den Vordergrund. Die technische Umsetzung ist immer nur Mittel zum Zweck. - E – Estimable (schätzbar)
Gute User Stories sind eindeutig formuliert, damit sie als Planungsgrundlage dienen können. Unschätzbare User Stories sind in der Regel zu umfangreich oder zu abstrakt. - S – Small (klein)
Gute User Stories können in einem einzigen Sprint umgesetzt werden. Nehmen sie mehr Zeit in Anspruch, liegt das meist an zu vagen Formulierungen. - T – Testable (testbar)
Gute User Stories sind objektiv überprüfbar. Ist ein Test nicht möglich, deutet das auf schwammige Formulierungen oder fehlendes Verständnis seitens der Beteiligten hin.
Die INVEST-Systematik stellt sicher, dass alle User Stories zuverlässig schätzbar sind (und das nicht nur, weil „schätzbar“ Teil der Mnemonik ist). Eine Story kann die sechs Anforderungen nur erfüllen, wenn sie eindeutig und klar formuliert ist. Dies sind Grundvoraussetzungen für jede verlässliche Aufwandsschätzung.
Abstrakte Schätzmethoden
Wie zeitliches Schätzen in der Praxis funktioniert, ist ganz einfach. Man weist einer Aufgabe eine zeitliche Dauer zu, die in etwa für die Umsetzung ausreicht. Relatives Schätzen ist ein abstrakter Prozess, der für viele Menschen intuitiv nicht greifbar ist. Deshalb muss das Projektteam im Vorfeld ein gemeinsames Schätzverfahren festlegen.
Relative Schätzgrößen (Story Points) in Form einer fortlaufenden Zahlenfolge (zum Beispiel 1, 2, 3, 4, …) sind weit verbreitet. Die Folge natürlicher Zahlen ist für diesen Zweck jedoch ungeeignet, denn sie ist zu feingranular. Sie provoziert nichtige Diskussionen, nur um einen Konsens zu erreichen. Für den Projektverlauf ist es zum Beispiel völlig unerheblich, ob eine User Story 32 oder 33 Punkte wert ist.
Deshalb ist die Fibonacci-Folge die eindeutig bessere Alternative. Hierbei entspricht jede Zahl der Summe der beiden vorherigen, beginnend mit 0 und 1: 0, 1, 1, 2, 3, 5, 8, 13, 21 etc. So können Teams kleine User Stories sehr granular abgrenzen. Zudem reduziert der Einsatz der Fibonacci-Folge mit steigender Komplexität den Spielraum für Diskussionen und Konflikte.
Es gibt auch abstrakte Schätzmethoden abseits von zahlenbasierten Systemen. Einige Teams verwenden beispielsweise T-Shirt-Größen (XS bis XXL), um Aufgabenpakete voneinander abzugrenzen. Das Prinzip ist dasselbe. Manche dieser Größen lassen sich sogar umrechnen. Die T-Shirt-Größe XS entspricht zum Beispiel einem Story Point.
Referenz-Stories
Relatives Schätzen ist eine klare Sache: Man stellt die Komplexität einer User Story in Relation. Dafür brauchen wir praxisnahe Vergleichswerte als Anker für weitere Schätzungen. Das Projektteam muss Referenz-Stories parat haben. Das Team schätzt zwei oder drei User Stories ein, die es gut abschätzen kann (oder sogar schon umgesetzt hat), und teilt ihnen entsprechende Werte zu. Jede weitere Schätzung kann das Team anschließend in Relation zu diesen Ankerpunkten setzen.
Dabei gibt es zwei Dinge zu beachten. Die Referenz-Stories müssen solide und von allen akzeptiert sein. Sie dürfen keinen Spielraum für Diskussionen bieten, sonst eignen sie sich nicht als Anker. Außerdem müssen die Referenz-Stories regelmäßig überprüft und gegebenenfalls ausgetauscht werden. Das Projektteam lernt mit der Zeit dazu und kann besser einschätzen, wie komplex eine Anforderung in Wirklichkeit ist. Durch das Update der Referenz-Stories verbessern Sie kontinuierlich die Präzision Ihrer Schätzungen.
Relatives Schätzen in der Praxis
Die Aufwandsschätzung der einzelnen User Stories wird immer vom gesamten Projektteam durchgeführt. Auch die Tester sind dabei, obwohl sie nicht direkt an der Implementierung mitwirken. Schließlich kann eine User Story in der Umsetzung trivial, aber im Testing sehr komplex sein. Das muss in der Sprintplanung berücksichtigt werden.
Das Projektteam muss ein klares und einheitliches Verständnis der User Story schaffen. Dann gibt jeder verdeckt eine Schätzung des Aufwands ab. Sind alle Teammitglieder einer Meinung, wird die Schätzung angenommen. Andernfalls muss eine Begründung der beiden Kollegen eingeholt werden, die nach oben und nach unten die größte Abweichung vom Konsens aufweisen. Das reicht in der Regel schon aus, um bei einer Neuschätzung einige Meinungen zu ändern und den Durchschnitt zu glätten.
Kleinere Abweichungen sind zweitrangig, gerade bei kleinen Aufgaben. Hier dauert die Diskussion teilweise länger als die Umsetzung. Im Zweifelsfall sollte sich das Team auf den höheren Wert einigen. Bei größeren Abweichungen sieht die Sache anders aus. Eine User Story, die mit 8 oder 15 bewertet wird, kann den Verlauf eines Sprints deutlich beeinflussen.
Der Prozess muss so stattfinden, dass sich die Schätzenden nicht gegenseitig beeinflussen. Einige Teams setzen dafür Spielkarten mit den verfügbaren Schätzwerten ein (Planning Poker). Es gibt auch Software-Lösungen, die den Input aller Teilnehmer zusammentragen und visualisieren. Gerade für lokal verteilte Teams sind solche Apps sehr praktisch.
Agile Aufwandsschätzung: Warum weniger manchmal mehr ist
In agilen Projekten sind zeitliche Aufwandsschätzungen auf der Basis von Erfahrungswerten in der Regel nicht möglich. Der flexible Charakter agiler Methoden und das komplexe Einsatzszenario machen es unmöglich. Stattdessen sollten agile Teams auf relative Komplexitätsschätzungen von User Stories ausweichen. Dabei weist das Projektteam jeder Story einen abstrakten Wert zu, der die Relation zu vergleichbaren Anforderungen repräsentiert. Das Ergebnis ist eine robuste Schätzung, die weitestgehend unabhängig von subjektiven Werten wie Arbeitstempo oder individuellem Fachwissen ist. Solche Schätzwerte eignen sich erfahrungsgemäß besser für agile Projekte. Aber man sollte es beim Schätzen nicht übertreiben, denn je mehr Zeit in Prognosen fließt, desto weniger Zeit bleibt für die Umsetzung. Projektteams sollten daher an dieser Stelle pragmatisch sein. Andernfalls besteht die Gefahr, dass die Aufwandsschätzung zu einem WOMBAT (waste of money, budget and time) wird.
