Für eine erfolgreiche Projektplanung ist eine präzise Aufwandsschätzung unerlässlich. Unternehmen müssen den Ressourcenbedarf frühzeitig kennen, um realistische Angebote erstellen zu können. In agilen Projekten stoßen traditionelle Schätzmethoden jedoch an ihre Grenzen. Unterschiedliche Arbeitstempi, wechselnde Anforderungen und die iterative Entwicklung machen exakte Prognosen schwierig. 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 usw. Dabei stützen sie sich auf Erfahrungswerte. Dieser Ansatz ist einfach und leicht zu vermitteln. Eine Autowerkstatt weiß beispielsweise genau, wie lange es dauert, einen Ölfilter für ein bestimmtes Fahrzeugmodell zu wechseln. Schließlich hat sie diesen Vorgang schon mehrfach durchgeführt.
In einem agilen Umfeld sind solche Erfahrungswerte jedoch weniger hilfreich. Das liegt unter anderem an der iterativen Natur agiler Projekte. Der Zyklus aus Planung, Implementierung, Test und Review macht es schwierig, den endgültigen Aufwand für ein Arbeitspaket vorherzusagen. Zum anderen werden agile Methoden in der Regel für komplexe Aufgaben eingesetzt, die grundsätzlich schwieriger zu schätzen sind.
Ein Mechaniker kann den Aufwand für einen Ölwechsel zeitlich genau vorhersagen. Wenn jedoch ein Kunde in der Werkstatt ein schleifendes Geräusch im Radkasten schildert, 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 zwar Schwierigkeiten damit, den genauen Aufwand für eine Aufgabe einzuschätzen, sie können jedoch gut beurteilen, ob eine Aufgabe komplexer ist als eine andere. Relationen zwischen Objekten sind hingegen ein bewährtes Vorgehen. Die exakte Körpergröße eines Kollegen zu bestimmen, ist unmöglich. 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.
Selbst wenn der tatsächliche Implementierungsaufwand einer Software-Funktion nicht bekannt ist, lässt sich ihre Komplexität im Vergleich zu einer bekannten Aufgabe ziemlich präzise einschätzen. Auf dieser Grundlage 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 und ist abhängig von der Projektkomplexität sowie 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
Das zeitliche Schätzen in der Praxis ist ganz einfach. Man weist einer Aufgabe eine Zeitdauer zu, die für die Umsetzung in etwa ausreicht. Das relative Schätzen ist ein abstrakter Prozess, der für viele Menschen nicht intuitiv greifbar ist. Deshalb muss das Projektteam im Vorfeld ein gemeinsames Schätzverfahren festlegen.
Weit verbreitet sind relative Schätzgrößen (Story Points) in Form einer fortlaufenden Zahlenfolge (zum Beispiel 1, 2, 3, 4, …). Die Folge natürlicher Zahlen ist für diesen Zweck jedoch ungeeignet, da sie zu feingranular ist. Sie provoziert nichtige Diskussionen, nur um einen Konsens zu erreichen. Für den Projektverlauf ist es beispielsweise völlig unerheblich, ob eine User Story 32 oder 33 Punkte wert ist.
Die Fibonacci-Folge ist deshalb die eindeutig bessere Alternative. Dabei entspricht jede Zahl der Summe der beiden vorherigen Zahlen, beginnend mit 0 und 1: 0, 1, 1, 2, 3, 5, 8, 13, 21 usw. So können Teams kleine User Stories sehr granular abgrenzen. Zudem reduziert der Einsatz der Fibonacci-Folge mit zunehmender 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. So entspricht die T-Shirt-Größe XS zum Beispiel einem Story Point.
Referenz-Stories
Beim relativen Schätzen stellt man die Komplexität einer User Story in Relation. Dafür sind praxisnahe Vergleichswerte als Anker für weitere Schätzungen notwendig. Das Projektteam muss Referenz-Stories parat haben. Das Team schätzt zwei oder drei User Stories, die es gut einschä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. Erstens müssen die Referenz-Stories solide und von allen akzeptiert sein. Sie dürfen keinen Spielraum für Diskussionen bieten, sonst eignen sie sich nicht als Anker. Zweitens müssen die Referenz-Stories regelmäßig überprüft und gegebenenfalls ausgetauscht werden. Mit der Zeit lernt das Projektteam 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 vorgenommen. Auch die Tester sind dabei, obwohl sie nicht direkt an der Implementierung mitwirken. Schließlich kann eine User Story in der Umsetzung trivial sein, im Testing jedoch sehr komplex. Dies muss bei der Sprintplanung berücksichtigt werden.
Zunächst muss das Projektteam ein klares und einheitliches Verständnis der User Story schaffen. Anschließend gibt jeder Teammitglied verdeckt eine Schätzung des Aufwands ab. Sind sich alle Teammitglieder einig, wird die Schätzung angenommen. Andernfalls müssen die beiden Kollegen, die nach oben und nach unten die größte Abweichung vom Konsens aufweisen, eine Begründung abgeben. In der Regel reicht das schon aus, um bei einer Neuschätzung einige Meinungen zu ändern und den Durchschnitt zu glätten.
Kleinere Abweichungen sind zweitrangig, insbesondere 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 gestaltet sein, dass die Schätzenden sich 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 Teilnehmenden 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 Basis von Erfahrungswerten in der Regel nicht möglich. Der flexible Charakter dieser Methoden und das komplexe Einsatzszenario machen dies unmöglich. Agile Teams sollten daher 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 weitgehend unabhängig von subjektiven Werten wie Arbeitstempo oder individuellem Fachwissen ist. Solche Schätzwerte eignen sich erfahrungsgemäß besser für agile Projekte. Beim Schätzen sollte man es jedoch nicht übertreiben, denn je mehr Zeit in Prognosen fließt, desto weniger Zeit bleibt für die Umsetzung. Projektteams sollten an dieser Stelle daher pragmatisch sein. Andernfalls besteht die Gefahr, dass die Aufwandsschätzung zu einem „WOMBAT” (Waste of Money, Budget and Time) wird.
