Inhaltsverzeichnis
Die Aufwandsschätzung ist ein elementarer Bestandteil der Projektplanung. Ein Unternehmen muss wissen, mit welchem Ressourceneinsatz im Projektverlauf zu rechnen ist. Andernfalls kann es kein verlässliches Angebot erstellen.
Liegen die Kalkulation und der reale Aufwand zu weit auseinander, sind Konflikte die Folge. Entweder kommt es zu Nachverhandlungen (ärgerlich für den Kunden) oder das Projekt wird unprofitabel (ärgerlich für den Anbieter).
Auch für agile Projektteams birgt die Schätzung von Aufwänden Konfliktpotential, denn die Umsetzungsdauer hängt von vielen Faktoren ab: Aufgabenverteilung, Arbeitstempo einzelner Mitarbeiter, Komplexität der Anforderungen etc. Hinzu kommt, dass agile Methoden häufige Rücksprachen mit dem Auftraggeber und eine sukzessive Weiterentwicklung des Konzepts vorsehen. Angesichts dieser Fülle an Faktoren kann das Projektteam gar nicht genau schätzen, wie lange die Umsetzung dauert.
In vielen agilen Frameworks ist die Aufwandsschätzung jedoch ein fester Bestandteil der iterativen Planung. Sie beeinflusst nicht nur die Angebotskalkulation, sondern auch die Implementierung der einzelnen User Stories. Die Schätzung muss sitzen, sonst gerät die Sprintplanung ins Wanken.
Zeitliche Schätzungen sind selten agil
Die meisten Menschen schätzen ihre Aufgaben in zeitlichen Dimensionen: Stunden, Tage etc. Als Grundlagen dafür verwenden sie Erfahrungswerte. Dieses Vorgehen ist einfach und leicht zu kommunizieren. Zum Beispiel kann eine Kfz-Werkstatt sehr gut abwägen, wie lange der Wechsel eines Ölfilters bei einem bestimmten Fahrzeugmodell dauert. Schließlich hat sie genau diesen Vorgang schon einige Male durchgeführt.
Im agilen Umfeld sind Zeitschätzungen weniger praktikabel. Das liegt zum einen an der iterativen Natur agiler Projekte. Der Kreislauf aus Planung, Umsetzung, Test und Review erschwert es, den finalen Aufwand eines Arbeitspakets vorherzusagen. Zum anderen kommen agile Methoden in der Regel bei komplexen Aufgaben zum Einsatz, die grundsätzlich schwerer zu schätzen sind.
Den Aufwand für einen Ölwechsel können Mechaniker zeitlich präzise voraussagen. Wenn ein Kunde jedoch in der Werkstatt ein schleifendes Geräusch im Radkasten beschreibt, das gelegentlich ab 120 Stundenkilometern bei niedrigen Außentemperaturen auftritt, sieht die Sache anders aus. In dem Fall können die Mechaniker dem Kunden nicht genau sagen, wie lange die Reparatur dauert.
Beide Faktoren haben zur Konsequenz, dass viele agile Teams auf zeitliche Schätzungen verzichten. Stattdessen verwenden sie die Komplexität der Aufgabe als Evaluierungskriterium.
Komplexität statt Zeit schätzen
Menschen tun sich meist schwer, absolute Größenordnungen einzuschätzen. Es fällt uns leichter, Relationen zwischen Objekten auszudrücken. Beispielsweise könnte ich nicht genau sagen, wie groß der Kollege am benachbarten Schreibtisch ist. Ich weiß allerdings, ohne nachzumessen, dass er etwas größer ist als ich.
Übertragen auf agiles Projektmanagement, ermöglicht Komplexitätsschätzung, Aufgabenpakete untereinander in Relation zu stellen. Auch, wenn ich den wahren Implementierungsaufwand einer Software-Funktion nicht kenne, kann ich trotzdem recht gut einschätzen, wie sie sich im Vergleich zu einer bekannten Aufgabe verhält. Darauf aufbauend kann ich beurteilen, ob eine Funktion in einem Sprint umsetzbar ist oder ob sie aufgeteilt werden muss.
Ein großer Vorteil von Komplexitätsschätzungen ist, dass sie zeitlich unabhängig sind. Die Umsetzungsdauer eines Aufgabenpakets kann variieren, abhängig von der Projektkomplexität und Lerneffekten des Teams. Der Komplexitätsgrad steht jedoch weitestgehend fest. Dadurch ist 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 einfach nachzuvollziehen. Man weist einer Aufgabe eine zeitliche Dauer (Arbeitsstunden, -tage, -wochen etc.) zu, die in etwa für die Umsetzung ausreicht. Relatives Schätzen ist allerdings ein abstrakter Prozess, der für viele Menschen intuitiv nicht greifbar ist. Daher muss sich das Projektteam im Vorfeld auf ein gemeinsames Schätzverfahren einigen.
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, denn sie ist zu feingranular. Sie provoziert nichtige Diskussionen, nur um einen Konsens zu erreichen. Für den Projektverlauf ist es zum Beispiel unbedeutend, ob eine User Story 32 oder 33 Punkte wert ist.
Als praxistaugliche Alternative hat sich die Fibonacci-Folge etabliert. Hierbei entspricht jede Zahl der Summe der beiden vorherigen, beginnend mit 0 und 1: 0, 1, 1, 2, 3, 5, 8, 13, 21 etc. Auf diese Weise können Teams kleine User Stories sehr granular abgrenzen. Gleichzeitig reduziert der Einsatz der Fibonacci-Folge mit steigender Komplexität den Spielraum für Diskussionen und Konflikte.
Abseits von zahlenbasierten Systemen gibt es auch andere abstrakte Schätzmethoden. Einige Teams verwenden beispielsweise T-Shirt-Größen (XS bis XXL), um Aufgabenpakete abzugrenzen. Das Prinzip ist das Gleiche. Zum Teil lassen sich die verschiedenen Schätzgrößen sogar umrechnen. Die T-Shirt-Größe XS entspricht zum Beispiel einem Story Point.
Referenz-Stories
Relatives Schätzen basiert darauf, die Komplexität einer User Story in Relation zu stellen. Damit das funktioniert, braucht es praxisnahe Vergleichswerte, die als Anker für weitere Schätzungen dienen. Zu diesem Zweck sollte das Projektteam Referenz-Stories parat haben. Es nimmt zwei oder drei User Stories, 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.
Hierbei gibt es zwei Dinge zu beachten. Zum einen sollten 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. Zum anderen empfiehlt es sich, die Referenz-Stories regelmäßig zu überprüfen und gegebenenfalls auszutauschen. Das Projektteam lernt mit der Zeit dazu und kann besser einschätzen, wie komplex eine Anforderung in Wirklichkeit ist. Indem Sie die Referenz-Stories aktuell halten, verbessern Sie stetig die Präzision Ihrer Schätzungen.
Relatives Schätzen in der Praxis
An der Aufwandsschätzung der einzelnen User Stories ist immer das gesamte Projektteam beteiligt. Das schließt auch die Tester mit ein, obwohl sie nicht unmittelbar 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.
Nachdem das Projektteam ein klares und einheitliches Verständnis der User Story geschaffen hat, gibt jeder verdeckt (um die anderen nicht zu beeinflussen) eine Schätzung des Aufwands ab. Sind alle Teammitglieder einer Meinung, wird die Schätzung angenommen. Andernfalls empfiehlt es sich, eine Begründung der beiden Kollegen einzuholen, 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 meist zweitrangig, gerade bei kleinen Aufgaben. Hier dauert die Diskussion teilweise länger als die Umsetzung. Im Zweifelsfall sollte sich das Team einfach auf den höheren Wert einigen. Bei größeren Abweichungen sieht die Sache anders aus. Ob eine User Story mit 8 oder mit 15 bewertet wird, kann große Auswirkungen auf den Verlauf eines Sprints haben.
Der Prozess sollte 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 aber auch Software-Lösungen, die den Input aller Teilnehmer zusammentragen und visualisieren. Gerade für lokal verteilte Teams sind solche Apps sehr praktisch.
Zusammengefasst
In agilen Projekten sind zeitliche Aufwandsschätzungen auf der Basis von Erfahrungswerten meist nicht möglich. Der flexible Charakter agiler Methoden und das komplexe Einsatzszenario lassen das nicht zu. Stattdessen sollten agile Teams auf relative Komplexitätsschätzungen von User Stories ausweichen. Hierbei weist das Projektteam jeder Story einen abstrakten Wert zu, der die Relation zu vergleichbaren Anforderungen repräsentiert. Dadurch ergibt sich eine robuste Schätzung, die weitestgehend unabhängig ist von subjektiven Werten, wie Arbeitstempo oder individuelle Fachkompetenz. Solche Schätzwerte eignen sich erfahrungsgemäß besser für agile Projekte.
Allerdings sollte man es beim Schätzen nicht übertreiben. Je mehr Zeit in Prognosen fließt, desto weniger steht für die Umsetzung zur Verfügung. Projektteams sollten an dieser Stelle pragmatisch sein. Sonst entwickelt sich die Aufwandsschätzung zu einem WOMBAT (waste of money, budget and time).
