Story-Points
Abschätzungen sind ein notwendiges Übel. Keiner macht sie gerne, aber wir brauchen sie, um unsere Projekte planen und die Kosten beziffern zu können. Beides ist – gerade im konventionellen Umfeld – meistens eine Voraussetzung für die Beauftragung eines Projektes und daher unerlässlich.
Zusätzlich sind sie aber auch im agilen Umfeld wichtig: Sie helfen uns dabei zu umfangreiche Stories zu identifizieren und sie in kleinere aufzubrechen.
Inhalt
Einheiten für Abschätzungen
In der Praxis begegneten mir bereits diverse unterschiedliche Einheiten zur Bezifferung von Abschätzungen.
Personentage
Die bekannteste Form ist sicherlich die Abschätzung in realen Aufwänden wie zum Beispiel Personenstunden beziehungsweise meist Personentagen. Der offensichtliche Vorteil dieser Variante besteht darin, dass der Aufwand in einer realen Maßeinheit angegeben wird, mit der jeder etwas anfangen kann. Aber die Lösung hat auch ihre Nachteile:
- Um den Aufwand in Personentagen beziffern zu können, muss zum Zeitpunkt der Abschätzung bereits geklärt sein, welcher Entwickler das Thema umsetzen wird. Schließlich verfügen unterschiedliche Entwickler über unterschiedliche Schwerpunkte und was der Eine »mal eben« nebenbei macht, erfordert vom Anderen erst eine aufwändige Einarbeitung.
- Gerade bei neuen Teams und/oder Technologien gehen wir davon aus, dass das Team am Anfang langsam ist, dann aber schneller wird. Das ist in der Abschätzung schwierig zu berücksichtigen, da die Beschleunigung nicht vorhersagbar ist und wir gegebenenfalls noch nicht wissen, in welcher Reihenfolge wir die Themen umsetzen werden. Somit muss die Abschätzung zu einem späteren Zeitpunkt nochmals durchgeführt werden, um sie an die gestiegene Geschwindigkeit anzupassen.
- Das Schätzen absoluter Aufwände ist schwierig – insbesondere wenn diese ein bis zwei Tage überschreiten. Angaben wie zum Beispiel 15 oder 20 Personentage sind höchst unzuverlässig.
- Häufig entstehen heftige Diskussionen, ob für ein Feature nun 6 oder 7 Personentage benötigt werden. Aufgrund der eh vorhandenen Ungenauigkeit sind solche Diskussionen reine Zeitverschwendung.
T‑Shirt-Größen
Diese Variante, bei der meist die Skala XS, S, M, L, XL verwendet wird, ist mir schon häufig im Rahmen von Grobabschätzungen begegnet. Hierbei handelt es sich um eine relative Abschätzung: Eine mit »M« abgeschätzte Story ist »irgendwie« kleiner als eine mit »L« abgeschätzte.
Relative Abschätzungen sind deutlich einfacher und somit auch schneller erledigt als absolute. Stell Dir vor Du stehst auf einer großen Kuhweide mit vielen Kühen. Es wird Dir leichtfallen festzustellen welche Kühe weiter weg sind als andere. Eventuell wirst Du sogar erkennen könne, dass eine bestimmte Kuh doppelt so weit von Dir entfernt ist wie eine andere. Die konkrete Entfernung einzuschätzen ist hingegen ausgesprochen schwierig. Das gelingt Dir vielleicht noch bis zu einer Distanz von zehn Metern, aber danach wirst Du weit daneben liegen.
Ein Nachteil der T‑Shirt-Größen besteht darin, dass sie keine Relation zueinander erkennen lassen. Da ich nicht weiß, ob »L« doppelt, viermal oder zehnmal so groß ist wie »M« ist eine Planung auf Basis solcher Abschätzungen nicht möglich. Daher werden sie meist für grobe Kosten-Nutzen-Analysen eingesetzt, um zu entscheiden, ob ein bestimmtes Feature umgesetzt werden soll oder nicht.
Story-Points
Bei Story-Points erfolgt die Abschätzung in abstrakten, aber numerischen Werten. Im Unterschied zu den realen Aufwänden wird in diesem Fall die Komplexität einer Anforderung abgeschätzt, wobei die Werte eine lineare Skala bilden. Eine mit vier Punkten abgeschätzte Story ist also doppelt so komplex wie eine mit zwei Punkten abgeschätzte.
Dadurch verbinden Story-Points die Vorteile einer relativen und somit einfacheren und schnelleren Abschätzung mit einer konkreten, numerischen Relation der Größen zueinander. Kennst Du erstmal die Geschwindigkeit Deines Teams (mehr dazu in einem späteren Artikel), so kannst Du Story-Points auch für Deine Planung nutzen.
Gerade im Vergleich zu den absoluten Aufwandsabschätzungen bieten Story-Points noch weitere Vorteile:
- Eine Beschleunigung des Teams – wie weiter oben beschrieben – kann leicht in der weiteren Planung berücksichtigt werden, ohne dass die Stories neu abgeschätzt werden müssen. Es genügt die höhere Geschwindigkeit bei der Planung einzubeziehen.
- Führst Du Deine Planung auf Basis von Story-Points und der Geschwindigkeit des Teams durch, so hast Du den üblichen Overhead schon in Deiner Planung berücksichtigt. Schafft Dein Team zum Beispiel 25 Story-Points pro Sprint, so sind dort ja bereits Nebentätigkeiten wie zum Beispiel Fehlerbehebung und organisatorischer Overhead enthalten.
Die Story-Point-Skala
Nun könnten wir für Story-Points einfach sämtliche natürliche Zahlen heranziehen um Abschätzungen zu beziffern. Also 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, … Der Nachteil dieses Vorgehens wären die bekannten und sinnlosen langen Diskussionen in den Abschätzungsrunden, ob eine Story nun 6 oder 7 Punkte Wert ist. Diesem Problem und der Tatsache, dass höhere Abschätzungen prinzipiell eh ungenauer sind, tragen wir Rechnung, indem wir nur eine eingeschränkte Menge von Zahlen zulassen.
Denkbar wären hier zum Beispiel die Zweierpotenzen (1, 2, 4, 8, 16, 32, …). In der Praxis etabliert hat sich aber die modifizierte Fibonacci-Reihe nach Mike Cohn. Diese stellt folgende Punktewerte zur Verfügung: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Ich persönlich nutze in meinen Teams die Werte 0 und 0,5 nicht, genauso wie die 100. Der Wert 40 bedeutet »wir haben keinen blassen Schimmer, was hier zu tun ist« und wird gerne als Puffer für vermutlich komplexe, noch zu analysierende Anforderungen verwendet.
Fazit
Story-Points bieten eine schöne Alternative zur konventionellen Abschätzung in Personentagen. Die Abstraktion von einem realen Wert und der Vergleich von Komplexitäten erleichtert dem Team die Abschätzung und uns die Anpassung der Planung an die Änderung der Geschwindigkeit des Teams.
Im nächsten Artikel zeige ich Dir, wie Ihr Eure Story-Point-Skala normiert und wie Du auf Basis von Story-Points Deine Planung durchführst.
Tags:Backlog, Backlog-Management, Planung, Scrum, User-Story
Trackback von deiner Website.
Verhoeven
| #
Danke!! für die fundiert dargestellten, mit Praxisbeispielen ›illustrierten‹ Erklärungen – bislang das beste, was ich bislang (in deutscher Sprache) gefunden habe.
Reply
Sven Wiegand
| #
Vielen Dank! Das freut mich zu hören.
Reply