Agiles Schätzen: 5 Gründe, warum wir nicht in Personentagen schätzen

Storypoints

Agiles Schätzen: 5 Gründe, warum wir nicht in Personentagen schätzen

Du sitzt da in der Runde, mit Planning Poker Karten in der Hand, und sollst in diesen komischen „Story Points“ schätzen. Und du fragst dich insgeheim: „Warum schätzen wir eigentlich nicht in Personentagen?“

Weil mir in CSM-Kursen Teilnehmer immer wieder genau diese Frage stellen, stelle ich hier nochmal die fünf wichtigsten Gründe zusammen, die für das Schätzen in relativer Größe sprechen.

Zunächst mal: Was sind eigentlich Story Points? Ganz einfach: Um zu wissen, wie schnell Dein Team ist, zähle einfach die Stories (oder Features oder Product Backlog Items), die es in einem Sprint fertigstellt. Das ist dann die Geschwindigkeit des Teams in diesem Sprint, also z.B. 9 Stories. „Halt!“ wirst du jetzt sagen. „Man kann doch nicht alle Stories über einen Kamm scheren. Da gibt’s doch größere und kleinere.“ Stimmt. Dann lassen wir einfach die großen doppelt oder dreifach oder nochmehr zählen und die kleinsten eben nur einfach. Jede Story bekommt 2, 3, oder eben nur einen Punkt. Und schwupps haben wir Story Points, sie drücken die relative Größe der Story aus. Die Geschwindigkeit ist nun die Summe der Story Points aller in einem Sprint abgeschlossenen Stories. Und das war’s auch schon.

Nun aber endlich zu den Vorteilen relativer Schätzungen mit Story Points!

Story Points sind stabiler als Zeitschätzungen

Scrum Teams lernen dazu und mit der Zeit deutlich schneller. Mit jeder neuen Erkenntnis und jeder internen Verbesserung ihrer Arbeitsabläufe müssten sie absolute Aufwände neu schätzen. Auch das Verschärfen der Definition-of-Done (ein typisches und sehr empfehlenswertes Vorgehen) würde eine Neuschätzung absoluter Aufwände nach sich ziehen. Story Points hingegen verändern sich dadurch nicht. So muss man wesentlich weniger Aufwand in das erneute Schätzen von Product Backlog Items stecken.

Teams schätzen relative Aufwände schneller und einfacher

Schätzungen sind – Vermutungen. Mit absoluten Schätzungen wird aber oft implizit das Versprechen verknüpft, dass ein Team auch in der Lage sein muss, ein Feature innerhalb der geschätzten Zeit umzusetzen. Das führt oft zu umständlich geführten und sehr detaillierten Diskussionen, bis man sich auf eine Schätzung einigen kann. Zur Ermittlung von Story Points hingegen gibt es Methoden, mit denen ein Team auch Dutzende Stories in sehr kurzer Zeit schätzen kann.

Hierzu eine Anekdote: ich habe einmal mit einem Team gearbeitet, das die klärenden Gespräche bei relativen Schätzungen sogar als so hilfreich empfunden hat, dass sie diese selbst in sehr unklaren Situationen eingesetzt haben, um zu schnell zu einem gemeinsamen Verständnis zu finden. Die entstandene Größenschätzung verwarfen sie anschließend!

Story Points sind unabhängig von Umsetzungsdetails

Der absolute Aufwand zur Umsetzung hängt natürlich davon ab, wer was genau tut. Das kann man aber nicht sinnvoll lange im Voraus festlegen. Bis zur konkreten Umsetzung hat sich die Lage sicher geändert, hat das Team neue Erkenntnisse gewonnen, sodass der sinnvollste Plan vermutlich anders aussehen wird. Die vorzeitige Festlegung von Umsetzungsdetails nur zum Zweck der Schätzung ist eine Verschwendung, die wir vermeiden möchten. Story Points ermöglichen genau das.

Storypoints sind fehlertolerant

Selbst wenn ein Development Team bei der Schätzung bestimmte Aspekte nicht berücksichtigt, z.B. die Automatisierung von Integrationstests, müssen Story Points nicht neu geschätzt werden. Sobald das Team seinen Fehler realisiert und im Sprint zusätzlich diese Arbeiten erledigt, sinkt seine Geschwindigkeit, die relative Größe der Stories hingegen ändert sich nicht.

Story Points kombinieren Expertenwissen aus verschiedenen Bereichen

Unterschiedliche Stories bergen unterschiedliche Herausforderungen. Manchmal ist das Design kniffelig, manchmal das Testen schwierig. All das sind Umsetzungsdetails, die für den Product Owner bei der Priorisierung des Backlogs nicht relevant sind. Story Points abstrahieren von diesen Details und kombinieren das Wissen des gesamten Teams in einer Schätzung.