Projekt Beschreibung

Viele Teams haben Schwierigkeiten damit, den Sprung von absoluten Schätzungen (z.B. in Personenstunden) zu relativen (z.B. Story Points) zu machen. In meinen Scrum-Trainings ist das oft eines der Themen, das am meisten Diskussionen verursacht. Wenn das Konzept nicht verstanden wurde, fallen die Teams häufig wieder zurück in die Abschätzung absoluter Zahlen – und nennen diese dann „Story Points“. In diesem Artikel betrachten wir das Konzept hinter absoluten Schätzungen, ohne dabei zu technisch zu werden. Beispielsweise gehen wir nicht auf Planning Poker ein. Wenn du dein Wissen hier weiter vertiefen willst, empfehle ich dir das Buch „Agile Estimating and Planning“ von Mike Cohn.

Warum schätzen wir überhaupt?

Das Ziel der agilen Schätzung ist Klarheit, nicht Sicherheit. In klassischen Projekten versucht man oft, absolute Sicherheit über den anfallenden Arbeitsaufwand zu erlangen – nur um dann im Projektverlauf festzustellen, dass man falsch lag. In Scrum schätzen wir, um besser zu verstehen, was der Product Owner möchte. Es geht um die Kollaboration, die entstehenden Schätzungen sind ein Nebenprodukt. Natürlich kann man diese Werte trotzdem für die Vorhersage von Releaseumfängen und -Zeiten nutzen (zumindest, wenn das Team stabil ist und eine eingeschwungene Velocity hat). Der viel größere Wert der Schätzung liegt aber in dem Umstand, dass das ganze Team die Wünsche des Product Owners verstanden hat und nun in der Lage ist, operative Entscheidungen zu treffen, die diesen Wünschen entsprechen.

Warum sollten wir relativ schätzen?

Scrum macht hier keine Vorgaben und erzwingt somit auch kein relatives Schätzverfahren. Übrigens gehören auch User Stories originär nicht zu Scrum (sondern zu eXtreme Programming). Scrum ist lediglich ein Rahmenwerk und ermöglicht es uns, jede Schätzmethode einzusetzen, die wir möchten. Das beinhaltet neben relativen Größen wie Story Points genauso absolute Zahlen wie Personenstunden oder Tage. Trotzdem gibt es drei sehr gute Gründe, relative Schätzverfahren zu wählen:

  1. Menschen sind relativ schlecht darin, Größen absolut zu schätzen. Dafür sind sie sehr gut darin, relative Unterschiede zu benennen. Betrachte diese beiden Steine und beantworte dir selbst die Frage: Wie groß ist der erste und wie groß ist der zweite (absolute Zahlen)? Danach stelle dir die Frage: Wieviel größer ist der zweite Stein im Vergleich zum ersten (relative Schätzung)? In aller Regel können wir die zweite Frage viel schneller und besser beantworten als die erste. Daher sind relative Schätzverfahren schneller und billiger als absolute.
  2. Menschen streiten sich im Regelfall nicht so viel, wenn es um relative Größen geht. Bei absoluten Größen ist der Streit jedoch vorprogrammiert: Ich habe schon viele Male Teams dabei ertappt, wie sie sich darüber gestritten haben, ob eine Aufgabe 6 oder 8 Stunden dauern wird. Mit 8 Entwicklern im Raum dauert es nur 15 Minuten, bis die Diskussion mehr Zeit und Geld kostet, als die Schätzunsicherheit betragen hat. Auch Diskussionen um die Frage, wer die Aufgabe abarbeiten wird, da dies ja die Schätzung beeinflusst, hilft aus Teamsicht nicht wirklich und fällt bei relativen Schätzungen weg.
  3. Man kann bei relativen Schätzungen bei Veränderungen des Umfelds (z.B. Wechsel eines Teammitglieds, Anwendung eines neuen Frameworks, schnellere Rechner, etc.) die Schätzungen beibehalten, während man bei absoluten Verfahren neu schätzen muss. Wenn man absolut geschätzt hat (z.B. in Tagen) und eine größere Veränderung tritt ein, muss man in aller Regel das ganze Backlog neu schätzen. Angenommen, du brauchst fünf Minuten mit deinem Fünf-Personen-Team, um ein einzelnes Backlog Item neu zu schätzen und du hast 100 Elemente im Backlog, dann kostet dich jede Neuschätzung des Backlogs fünf Personentage. Diese Prozesskosten fallen bei absoluten Schätzungen bei jeder größeren Veränderung des Umfelds an. Bei relativen Schätzungen investiert man diesen Aufwand nur einmal, denn bei Veränderungen bleibt die relative Größe konstant. Was sich verändert ist die Velocity, also die Abarbeitungsgeschwindigkeit. Diese wiederum wird nicht geschätzt, sondern gemessen. Damit entfällt zusätzlicher Schätzaufwand.

In welcher Einheit sollten wir schätzen?

Bei relativen Schätzungen gibt es mitunter Diskussionen über die „richtige“ Einheit, in der geschätzt werden sollte. Manche Menschen bevorzugen „Komplexität“, andere sprechen über „Aufwand“ und wieder andere haben noch bessere Ideen. Man kann viele Stunden über diese Frage streiten, oder sich die Zeit sparen und lieber dem Teamziel zuwenden. Denn: Alle Meinungen sind gleichermaßen richtig! Es spielt keine Rolle, welche Einheit man wählt, solang das ganze Team der Wahl zustimmt. Das ist etwas schwieriger, wenn man sich für „Aufwand“ entscheidet, da dieser durch viele Faktoren bestimmt wird und man stärker dazu neigt, absolute Größen anzuwenden. Auch „Komplexität“ hat ihre Tücken, denn jeder versteht etwas anderes darunter und man muss den Begriff zunächst im Team normieren. Man kann den Prozess verkürzen, wenn man stattdessen den Begriff „Größe“ verwendet. Größe ist neutral, nicht direkt mit dem Aufwand verknüpft und mit Komplexität lose gekoppelt. Das Beste daran ist aber, dass wirklich jeder ein ähnliches Verständnis dieses Begriffs hat!

Warum werden die Fibonacci-Zahlen so häufig eingesetzt?

Die meisten Scrum-Teams setzen eine Form von angepasster Fibonacci-Sequenz zum relativen Schätzen ein. Die Fibonacci-Folge entsteht, wenn eine Zahl immer die Summe der zwei vorhergehenden Zahlen darstellt. Die „echte“ Fibonacci-Folge lautet also: 1-1-2-3-5-8-13-21-34-55-89 etc. Die meisten Teams passen diese allerdings an und verwenden beispielsweise 1-2-3-5-8-13-21-40-100. Die Gründe dafür sind naheliegend:

  1. Wenn man einen Entwickler fragt, um wieviel größer etwas im Vergleich zu etwas anderem ist, wird dieser meist mit „doppelt so groß“ antworten und die Kollegen werden zustimmend nicken. Das verhindert den Austausch unterschiedlicher Ansichten. Bei Fibonacci gibt es „doppelt so groß“ aber (fast) nicht, was die Entwickler zwingt, sich für eine Zahl zu entscheiden. Manche wählen den größeren, manche den kleineren Wert. In jedem Fall müssen sie ihre Entscheidung begründen. Hieraus entstehen die wertvollen Einsichten und Perspektiven, um die es uns eigentlich geht. So werden viele unterschiedliche Sichten auf das geschätzte Element beleuchtet.
  2. Viele Teams halten sich nicht an die „reine“ Fibonacci-Folge, weil die Zahlen in den höheren Regionen (34, 55, 89, …) eine Präzision vermitteln, die so nicht existiert. 34 klingt einfach viel genauer als 40, während man bei komplexen Aufgaben eigentlich vermitteln möchte, dass die Genauigkeit der Schätzung abnimmt. Stark vereinfacht gesagt ist die Botschaft des Teams an den Product Owner bei 40 oder 100 lediglich, dass das Product Backlog Item zu groß ist und verfeinert werden muss.
  3. Bei Fibonacci nimmt außerdem die Größe der Lücken zwischen den Zahlen zu. Das illustriert den Beteiligten, dass Schätzungen mit zunehmender Größe der geschätzten Elemente weniger zuverlässig werden. Auch nimmt der Bedarf an Präzision ab. Wieso sollte man sich darüber streiten, ob ein Element 38 oder 39 Punkte groß ist? Lasst uns 40 hinschreiben, genauer wird es eh nicht!

In Summe ist die (angepasste) Fibonacci-Folge hervorragend dazu geeignet, den Austausch im Team und mit dem Product Owner zu unterstützen.

Kann man auch andere Schätzgrößen verwenden?

Na klar! Bisher habe ich neben Story Points auch T-Shirt-Größen (XXS bis XXXL) und Tiere (Ameise, Frosch, …, Giraffe, Elefant) genutzt. Die Abkehr von Zahlen hilft den Schätzenden dabei zu verstehen, dass es um relative Größen geht und nicht um absolute Zahlen. Was ist der Aufwand eines Elefanten? Was ist die Komplexität einer Giraffe? Ich habe keine Ahnung. Aber die Größe kann ich sehr leicht schätzen.

Wie genau funktioniert das Schätzen in relativen Einheiten?

Am liebsten erkläre ich das mit einem Bild von Steinen. Stell dir vor, du hättest drei Haufen mit Steinen:

Innerhalb eines Haufens sind alle Steine gleich groß, die Anzahl ist klar ersichtlich. Sagen wir, ein Stein aus dem ersten Haufen erhält als Größe die Nummer 2 (zwar ist es aktuell der kleinste Stein, aber irgendwann findet man immer einen noch kleineren). Jetzt haben wir eine Referenz willkürlich definiert und können den Rest relativ dazu schätzen. Wir bitten also das Team, einen Stein aus dem zweiten Haufen im Vergleich zu einem Stein aus dem ersten Haufen zu schätzen. Jeder wird sich für eine Zahl entscheiden und wir teilen unsere unterschiedlichen Sichten. Am Ende einigt man sich auf einen Wert, in unserem Beispiel vermutlich auf die 5. Dieses Vorgehen wiederholen wir für den dritten Haufen, der nun schon gegen zwei Referenzwerte geschätzt werden kann. Möglicherweise einigen wir uns hier auf die Größe 13. Bitte beachte, dass wir bislang nicht darüber gesprochen haben, was wir mit diesen Steinen anstellen wollen oder wer die Arbeit übernehmen soll. Wir haben lediglich über die Größe diskutiert und Zeit gespart.

Um den Gesamtumfang unseres Backlogs zu errechnen, summieren wir die Schätzungen der einzelnen Steine in dem Haufen auf. Unser Backlog besteht also aus Elementen mit der Gesamtgröße 51 (10*2 + 3*5 + 2*13).

Das war bisher recht einfach, aber wir haben noch nichts mit den Steinen gemacht. Das lässt sich ändern:

Stell dir vor, dein Chef ist eine sehr unangenehme und nachtragende Person. Heute Morgen hast du ihn nicht gegrüßt. Daher hat er jetzt einen Spezialauftrag für dich: Du darfst alle Steine von einem Ende der Stadt ans andere tragen. Mit bloßen Händen und ohne Werkzeuge. Wenn alle drüben angekommen sind, darfst du sie wieder auf dem gleichen Weg zurücktragen usw. Unser Backlog ist also unendlich groß, die Steine werden uns nie ausgehen. Wir einigen uns auf eine Sprintlänge von einer Woche. Zu diesem Zeitpunkt wissen wir noch nicht, wie lange du brauchen wirst, um alle Steine einmal durch die Stadt zu tragen, es gibt also noch keine Verbindung zwischen der Größe der Steine und Zeit bzw. Aufwand. Nehmen wir an, dass du mit der Arbeit beginnst und die ganze Woche brauchst, um alle Steine einmal durch die Stadt zu tragen. Du hast also innerhalb eines Sprints zehn kleine Steine, drei mittelgroße Steine und zwei riesige Felsbrocken zum Ziel bewegt. Deine Velocity des ersten Sprints ist damit 51 – die Summe aller Steingrößen, die du komplett durch die Stadt bewegt hast.

Velocity 1 = 51

Dein Chef ist immer noch sauer und zwingt dich, die Steine weiterhin von A nach B und zurück zu tragen. Das Gute daran ist, dass du in Form kommst und deine Muskeln stärker werden. Du siehst jetzt nicht nur sportlicher aus, sondern bist auch schneller im Steine schleppen. Du schaffst es jetzt, alle Steine innerhalb einer Woche zweimal quer durch die Stadt zu tragen. Du hast also innerhalb eines Sprints zwanzig kleine Steine, sechs mittelgroße Steine und vier riesige Felsbrocken zum Ziel bewegt. Die neue Velocity ist damit 102.

Velocity 2 = 102

Die Größe der Steine hat sich nicht dadurch verändert, dass du Muskelmasse aufgebaut hast. Was sich verändert hat, ist die Geschwindigkeit, mit der du sie trägst.

Stell dir jetzt vor, dass dein Chef einen gnädigen Moment hat. Er erlaubt dir, öffentliche Verkehrsmittel zu benutzen. Du schaffst es damit, innerhalb einer Woche alle Steine viermal quer durch die Stadt zu transportieren. Damit hast du eine Velocity von 204 erreicht.

Velocity 3 = 204

Die Größe der Steine hat sich nicht verändert, obwohl du jetzt das neue Framework „öffentliche Verkehrsmittel“ benutzt. Was sich verändert hat, ist die Geschwindigkeit, mit der du die Steine bewegst.

Wie dir sicher schon aufgefallen ist, mussten wir die Größe der Steine zu keinem Zeitpunkt neu schätzen. Auch haben wir nie darüber gesprochen, wie lange es wohl dauern wird, einen Stein durch die Stadt zu tragen. Die Zeitkomponente ergibt sich automatisch in Kombination der Schätzung mit Sprintlänge und Velocity. Dein Chef kann trotzdem jederzeit eine Prognose über die Lieferzeitpunkte abgeben, weil er die geschätzten Größen und die gemessene Velocity kennt.

Dieses Prinzip gilt natürlich auch entsprechend in der Softwareentwicklung und in allen anderen Schätzszenarien. Besonders hilfreich ist es im komplexen Bereich, wo sich viel ändert und man häufiger absolut geschätzte Elemente neu abschätzen muss, um aussagefähig zu bleiben.

Bei relativen Schätzungen ist es egal, ob man die zu schätzende Aufgabe schon tausendmal gemacht hat, hübsche neue Tools hat oder ob eine unerfahrene (oder sehr erfahrene) Person die Umsetzung erledigen wird. Die Schätzung bleibt gleich. Was sich ändert, ist die Velocity.

Sollten wir Unterschiede in unseren Schätzungen nicht diskutieren?

Der Drang die „richtige“ Schätzung zu finden ist groß. Das hat aber einen entscheidenden Nachteil: Wenn wir unsere unterschiedlichen Sichten nicht einfach nur teilen, sondern sie aktiv diskutieren, dann werden tendenziell Argumente bevorzugt, die von stärkeren Persönlichkeiten geäußert werden. Wer etwas sagt wird damit manchmal wichtiger, als was gesagt wird. In Summe heißt das, dass bei einer Diskussion die Teammitglieder in ihren Schätzungen stärker beeinflusst werden, als notwendig. Beim einfachen Teilen unterschiedlicher Sichten passiert das weniger stark.

Wie kommen wir zu einer guten Schätzreferenz?

Manche Teams schätzen grundsätzlich im Vergleich zu den Elementen des letzten Sprints. Das führt allerdings zu schleichendem Verfall (“sizecreep”), denn die Entwickler beginnen unwillkürlich mit wachsender Erfahrung die Größe von Backlog Items kleiner einzuschätzen. Das liegt daran, dass wir meistens implizit in Aufwand denken, auch wenn wir über relative Größe sprechen. Im Ergebnis steigt die Leistung des Teams zwar, die Velocity bleibt aber unverändert, obwohl sie entsprechend der Leistung steigen sollte. Das muss zwar nicht schlecht sein, kann aber leicht vermieden werden. Der Schlüssel dazu ist eine Schätzreferenz. Nimm beispielsweise ein Flipchart und schreibe die Schätzkategorien (z.B. 1, 2, 3, 5, 8, 13, 21) darauf. Nach jedem Sprint schaut ihr als Team auf die abgeschlossenen Elemente dieses Sprints und fragt euch, welche der Schätzungen richtig gut waren. Diese Items nehmt ihr dann in die Schätzreferenz auf und schreibt sie auf das Flipchart (z.B. auf Klebezetteln). Wenn ihr dann neue Elemente schätzt, nutzt ihr dieses Flipchart als Referenz und nicht den letzten Sprint oder Bauchgefühl. Auf diese Weise bleibt die Referenz stabil, was zu stabileren Schätzungen und einer sich verändernden Velocity führt.

Los geht’s!

Ich hoffe, dieser Artikel hat dir dabei geholfen, relatives Schätzen besser zu verstehen. In unserem Agile Essentials Training, dem Professional Scrum Master Training sowie beim Professional Scrum Product Owner Training üben wir das auch live.

Viel Spaß und Erfolg mit deinem Team!

Folgende Beiträge könnten dich auch interessieren