5 minutes reading time (922 words)

Ist Schätzen Erbsenzählerei? | Aufwandsschätzung Teil 2

Ist Schätzen Erbsenzählerei? | Aufwandsschätzung Teil 2

In Teil 1 unserer Serie haben wir uns mit der Frage beschäftigt, warum Aufwandsschätzungen in agilen Projekten so schwierig sind. Obwohl es bei komplexen Projekten praktisch unmöglich ist, soll meist bereits zu Beginn prognostiziert werden, bis wann und mit welchem Aufwand ein Ergebnis geliefert wird, das noch gar nicht exakt definiert werden kann. Agile Teams sehen in dieser Forderung der Auftraggeber unsinnige „Erbsenzählerei“, die dem Projekt mehr schadet als nützt - die Auftraggeber hingegen ärgern sich über nicht eingehaltene Deadlines und Budget-Überschreitungen. Sogenanntes „abstraktes Schätzen“ kann dazu beitragen, diese unterschiedlichen Erwartungshaltungen auf einen Nenner zu bringen. Aber was unterscheidet die Methoden rund um „Story Points“ und „Velocity“ von der klassischen Aufwandskalkulation? Und kann man sich im agilen Umfeld diese ganze Schätzerei nicht sowieso sparen?

Sorry, aber ohne Schätzen geht’s nicht!

Vorweg: Egal ob agil oder klassisch, Schätzungen sind wichtig. Weniger weil sie Auftraggebern das Gefühl der Risikominimierung (und den Teams einen zeitlichen und monetären Rahmen) geben. Viel wichtiger ist meines Erachtens die Schätzung als erster Abgleich, ob beide Seiten überhaupt von denselben Voraussetzungen ausgehen: Stark voneinander abweichende Kalkulationen sind ein gutes Indiz dafür, dass Anforderungen unterschiedlich verstanden wurden. Damit ist die Schätzung ein wesentlicher Bestandteil der Vereinbarung zwischen Auftraggeber und Auftragnehmer bzw. zwischen Product Owner und Team. Und auch bei Sprint-Planungen und Roadmaps greifen Teams auf Schätzungen zurück.

Die schlechte Nachricht: Schätzen ist immer ungenau.

Eine Schätzung ist und bleibt eine Schätzung. Und je früher im Projektzyklus geschätzt wird, desto höher ist der Unsicherheitsfaktor. Im Projektverlauf nimmt die Unsicherheit stetig ab, erreicht aber erst mit Projektende 0 Prozent. Diese Unsicherheitskurve in Abhängigkeit von der Projektphase wird auch als "Cone of Uncertainty" bezeichnet – mit der logischen Konsequenz, dass Aufwandsschätzungen laufend aktualisiert werden sollten, um neue Informationen und Erkenntnisse zu berücksichtigen.

Schätzen hat nichts mit Bauchgefühl zu tun.

Während mit klassischen Methoden wie Delphi oder Cocomo (mehr dazu in Teil 3 dieser Serie) das komplette Lastenheft analysiert und mit konkreten Zeiten und Kosten hinterlegt wird, wird in agilen Projekten abstrakt geschätzt.

Dazu ein kleines Anschauungsbeispiel – bleiben wir beim Erbsenzählen:

Wie schätzen Sie möglichst zuverlässig, wie viele Erbsen auf dem untenstehenden Bild zu sehen sind?

Vermutlich würden Sie ähnlich wie ich einen kleinen Teil des Bildes auszählen (oder grob schätzen) und dann hochrechnen. Doch ganz so einfach ist es bei den meisten Projekten nicht. Was wenn die Erbsen übereinander liegen - oder wenn gar nicht ersichtlich ist, wie viele Erbsen sich in einer Schote verbergen?

Die absolute Zahl zu schätzen wird nun schon deutlich schwieriger. Die Lösung: Beim abstrakten Schätzen wird die Fähigkeit genutzt, Mengen miteinander in Relation zu setzen. Denn die Aufgabe wird sehr viel einfacher, wenn Sie lediglich zwei Mengen vergleichen sollen: Welches Glas enthält mehr Erbsen?

Von Erbsen zu Story Points, Velocity & Co.

Analog funktioniert das abstrakte Schätzen in agilen Projekten: Zuerst wird das Projekt in kleine „Häppchen“ (User Stories) aufgeteilt, die sich gut schätzen lassen. Die einzelnen Stories sollten deshalb innerhalb von ein bis zwei Wochen umsetzbar sein.

Und dann wird es spannend: Charakteristisch für abstrakte Schätzungen ist die Trennung zwischen Umfang und Aufwand eines Features. Geschätzt wird also nicht in absoluten Zeitmaßen wie Stunden, Tagen oder Monaten, sondern das Team vergibt für die Größe und Komplexität einer User Story sogenannte „Story Points“. Diese Schätzung ist umso näher an der Realität, je größer der Erfahrungsschatz ist, der vom Team eingebracht wird. So kann das Team verschiedene User Stories miteinander vergleichen – ist die Komplexität ähnlich, größer, kleiner? Eine User Story mit 6 Story Points hat also voraussichtlich einen doppelt so großen Umfang wie eine User Story mit 3 Story Points usw.

Nun sagen Story Points als abstraktes Schätzmaß dem Auftraggeber noch gar nichts über Projektdauer und Projektkosten. Die Story Points müssen also noch in ein absolutes Maß „übersetzt“ werden. Der Umrechnungskurs für Story Points ist die sogenannte „Velocity“ – die Geschwindigkeit, in der das Team Story Points je Zeiteinheit umsetzen kann. Dieser Faktor basiert üblicherweise auf gemessenen Erfahrungswerten (aus vorangegangenen Projekten oder bereits umgesetzten Features) und schwankt von Team zu Team.

Ist das alles nicht sehr kompliziert?

Was auf den ersten Blick vielleicht im wahrsten Sinne des Wortes "abstrakt" erscheint, ist in der Praxis genial: Denn durch die Trennung von relativer Komplexität und absolutem Aufwand können Schätzungen abgegeben werden, ohne das umsetzende Team zu kennen. Wie schnell sind die einzelnen Teammitglieder? Fällt vielleicht ein besonders erfahrener Mitarbeiter wegen Krankheit aus? Steigt die Teamgeschwindigkeit mit zunehmender Routine während des Projekts? All diese Faktoren spielen bei der Vergabe der Story Points keinerlei Rolle, was den Schätzungsvorgang schnell und objektiv macht und die Arbeit in crossfunktionalen Teams erleichtert. 

Entsprechend hoch ist die Akzeptanz in den Teams. Abstraktes Schätzen ist leicht zu lernen und kostet vergleichsweise wenig Zeit – und es gibt den Teams Autonomie, was erfahrungsgemäß sehr motiviert. Alle Mitarbeiter des Teams schätzen die Story Points gemeinsam und können sich so mit ihren selbst gesteckten Zielen besser identifizieren.

Unser Fazit: Nein, die Forderung von Auftraggebern nach Schätzungen ist keine Erbsenzählerei. Schätzen ist sinnvoll - wenn sich alle Beteiligten bewusst sind, dass Schätzungen je nach Projektfortschritt und Informationsstand einen entsprechenden Unsicherheitsfaktor beinhalten. Und wenn das Team nur so viel Zeit in Schätzungen investiert wie es dem Projekt nützt.

Übrigens macht abstraktes Schätzen Spaß - verschiedene Methoden wie den bewährten „Schätzpoker“ werden wir in Teil 3 unserer Serie detailliert vorstellen, ebenso wie wichtige klassische Schätzverfahren.

Haben Sie Fragen zur Aufwandsschätzung oder zu einer speziellen Schätzmethode? Melden Sie sich gerne bei uns! Auch in unserer Schulung "Anforderungsmanagement 4.0" lernen Sie agiles Schätzen.

 


Bildnachweis:
pixpack / 123RF
123bogdan / 123RF
paylessimages / 123RF
2002lubava1981 / 123RF
alekseykh / 123RF

Was ist eigentlich ... intrinsische Motivation?
Coaching will gerlernt sein - ein Erfahrungsberich...