Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Das Wetter von gestern

Ein Thema, das nicht nur Entwicklungsteams und Manager, sondern auch gestandene Scrum-Consultants oftmals nicht in Ruhe lässt, ist das Schätzen. Auch als junger Berater muss man sich zunächst einmal umfassend orientieren und Dinge als gegeben akzeptieren, auch wenn man sie noch nicht richtig durchblickt. Manches leuchtet einem ganz intuitiv ein, bei manchem fragt man sich erstmal, ob das ernst gemeint sein kann. Das Schätzen ist – zumindest für mich – gerade deshalb ein Sonderfall, weil sich bei mir gleichzeitig ein sofortiges Vertrauen in die Praktikabilität der Methode sowie ein tiefes Misstrauen gegenüber dem zugrundeliegenden Mechanismus einstellten.

Schätzen in Scrum bedeutet: Funktionalität schätzen, nicht Aufwand. Und das in Storypoints – das klingt zunächst einmal etwas befremdlich, ist aber kein Hexenwerk. Traditionelle Schätzverfahren liefern allzu oft nicht zufriedenstellende Ergebnisse, und das bedeutet: Die Zahl der geschätzten Bearbeitertage, Nettoarbeitsstunden usw. passt nicht zum tatsächlichen Aufwand. Arbeitszeit ist somit zwar eine reelle Größe, aber eine, die nur sehr schlecht schätzbar ist. (Insbesondere natürlich dann, wenn diese „Schätzung“ ganz plötzlich und wie von selbst als in Stein gemeißelt erscheint und absolute Präzision suggeriert.) Funktionalität als messbare Größe ist dagegen nicht so leicht zu fassen. Sie lässt sich besser schätzen als der Aufwand, bietet jedoch keinen reellen Gegenwert für diese Schätzung – und beides soll man als Vorteil ansehen! Wie kann das sein?

Zunächst einmal sorgt die schwere Fasslichkeit von Funktionalität als Schätzgröße dafür, die Aufmerksamkeit des schätzenden Teams von bekannten und lieb gewonnenen Größen wie Aufwand, Bearbeitertagen, usw. abzulenken, und damit auch die Illusion eines allzu präzisen Schätzverfahrens, wie es de facto nicht zu erreichen ist – eben weil es sich lediglich um Schätzungen handelt.

Der Glaube an das Schätzen in Storypoints ist leicht begründbar: Es funktioniert intuitiv. Man muss sich nicht einmal ein richtiges Experiment mit Zetteln und Fibonacci-Zahlen auszudenken, sondern braucht lediglich an zwei oder mehr Dinge zu denken und diese im Hinblick auf irgendeine Eigenschaft zu vergleichen, die ominöse „Funktionalität“ eingeschlossen: Was kann mehr? Handy oder Glühbirne? Das Handy! Radiowecker oder Fernbedienung? Der Radiowecker! Und alle vier zusammen? Handy, Radiowecker, Fernbedienung, Glühbirne. Ist jemand anderer Meinung? Egal, war ja nur geschätzt. So weit, so gut – alles mit Bauchgefühl.

Doch an dieser Stelle regt sich Widerstand im Hirn: Moment! Angeblich braucht dieses Schätzen keine Bezugsgröße – wozu soll es dann gut sein? Ohne Bezugsgröße ist die Schätzung völlig willkürlich, egal, ob ich nur eine Reihenfolge erstelle, Fibonacci-Zahlen oder Kleidergrößen vergebe:

Glühbirne – Fernbedienung – Radiowecker – Handy

Glühbirne: 2 – Fernbedienung: 3 – Radiowecker: 5 – Handy: 8

Glühbirne: S – Fernbedienung: M – Radiowecker: L – Handy: XL

Solange ich diese Größen nicht in Bezug zu einer Normgröße setzen kann, nutzen sie mir doch nicht das Geringste! Das Ziel des Schätzens ist es schließlich, eine Voraussage für die Zukunft zu treffen: Wiederholtes Schätzen führt zu halbwegs stabilen Wertverteilungen, die wiederholte Ermittlung der Team-Velocity erlaubt eine Annahme über die zu erwartende Entwicklungsleistung des Teams in einem gegebenen Zeitraum. Also muss, wer seriös und erfolgreich schätzen will, seine Schätzungen in Abhängigkeit von der empirisch bestimmten Bezugsgröße „Team-Velocity“ betrachten, wodurch wiederum eine klassische Aufwandsschätzung vorliegt, da Velocity nichts anderes bedeutet als Entwicklungsleistung pro Sprint.

In dieser (zumindest vordergründig) sehr einleuchtenden Feststellung liegt der Grund der ganzen Verständnisschwierigkeit verborgen: Denn Velocity ist als Größe nur in eine Richtung erfassbar, sie liefert eindeutige Aussagen lediglich über die Vergangenheit, d.h. die bereits abgeschlossenen Sprints. Für die Zukunft können aus einer (angemessen eingependelten) Velocity wiederum nur Schätzungen abgeleitet werden – mit entsprechend einzuplanenden Abweichungen. Als Normgröße im absoluten Sinne kann sie daher niemals gelten, schon deshalb nicht, weil sie keine echte Größe ist – denn wie sollte man Funktionalität exakt bestimmen und messen? Funktionalität ist eine Pseudogröße, ein relationales Konstrukt. Daher rühren auch die Anfangsschwierigkeiten, die beim Schätzen mit Storypoints so oft zu beobachten sind: Was soll das heißen, die Story ist eine „3“? Es bedeutet nichts. Nichts, außer der Tatsache, dass das schätzende Team die in dieser Story enthaltene Funktionalität im Vergleich zu jener anderer Storys mit einer 3 einschätzt, größer als 2, kleiner als 5. Die Summe der so pro Sprint geschätzten und abgearbeiteten Storypoints ergibt bekanntlich die aktuelle Velocity.

Das sehr empfehlenswerte Video „Agile Product Ownership in a Nutshell“  bringt es auf den Punkt: „Velocity is like yesterdays weather.“ Sie ist ein Erfahrungswert, von dem aus wir auf die Zukunft extrapolieren können, mehr nicht – denn wir haben zwar die Velocity als „exakte Messgröße“, aber keinen Mechanismus, um diese Rückschau in eine exakte Voraussage für die Zukunft ummünzen zu können.

Die Allegorie lässt sich noch ausbauen: So wie die Meteorologie durch immer neue Berechnunsgmodelle und durch zusätzliche Messdaten immer genauer prognostizieren kann, wie das Wetter wohl werden wird, so wird auch die geschätzte Velocity eingespielter Teams immer näher an die Realität rücken. Dennoch kann bis heute niemand sagen, ob er morgen bei einer Regenwahrscheinlichkeit von 70% nass wird oder nicht – denn diese besagt nicht, dass es 70% des Tages regnet oder in 70 % des betrachteten Gebietes, sondern lediglich, dass in 70% der Fälle mit vergleichbarer Wetterlage auch Regen fällt. Das ist eine sehr gute Vorhersage, aber eben auch nicht mehr.

TIPP: Boris Gloger: Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind. Hanser 2014.

  • sw

    Ein sehr schöner Vergleich, wie ich finde :)

  • Dennis

    Schön geschrieben, gut gesagt und immer wieder sehr wichtig!