Immer wieder höre ich gerade bei neu aufgesetzten Teams die Frage, wieso man eigentlich zu Beginn eines Projekts oder einer Iteration in Storypoints schätzt und nicht direkt in Stunden. Die Antwort ist einfach – Storypoints sind schlichtweg die bessere Schätzgröße, aber warum?
- Storypoints beschreiben nicht den individuellen Aufwand einzelner Personen, sondern den Aufwand eines Teams.
- Storypoints unterliegen weniger kleinen Variationen in der Schätzung des Teams.
- Storypoints sind für ein konstantes Team eine dauerhafte Messgröße für die Entwicklungsgeschwindigkeit.
- Der Wert einer Story rückt stärker als der vermeintlich exakte Aufwand in Stunden in den Vordergrund
Zu 1) Es ist ganz natürlich, wenn man in Größen schätzt, mit denen man täglich zu tun hat. Häufig rechnen Teilnehmer einer Schätzrunde für sich Stunden in Storypoints hoch oder andersrum. Schätzung in Stunden ist gelernt, aber die Tatsache, dass etwa 70% aller (in Stunden/Tage) geschätzter Projekte nicht im geschätzten Aufwand fertig werden, sollte Gegenargument genug sein. Das Problem in Teams ist, dass es sowohl in der Schätzung, als auch in der Umsetzung zwischen einzelnen Personen des Teams gravierende Unterschiede gibt, die manchmal sogar Tagesform abhängig sind. Abweichungen zwischen einer und 25 Stunden sind keine Seltenheit. Storypoints sind also eine von Stunden zunächst losgelöste Betrachtung der Komplexität und beschreibt am Ende einen Wert, auf den sich das gesamte Team geeinigt hat.
Zu 2) Im Kontext eines Gesamtprojekts gesehen ist es nicht entscheidend, ob eine einzelne Aufgabe daraus 10 oder 12 Stunden Aufwand sind – abhängig von der Projektgröße kann es auch eine geringe bis keine Relevanz haben, ob eine Aufgabe 1 oder 4 Tage braucht. Wenn die Anzahl der zu schätzenden Aufgaben groß genug ist, wird es ausreichend andere Aufgaben geben, die diesen Detailgrad nivellieren. Ziel ist es also nicht, sich in einer frühen Phase des Projekts mit langen Diskussionen auf einen genauen Stundenwert einzelner Aufgaben zu einigen (der ohnehin in 70% der Fälle nicht getroffen wird), sondern im Mittel für das gesamte Projekt einen guten Schätzwert zu erreichen.
Zu 3) Für Unternehmen oder Product Owner ist Kenntnis über die Geschwindigkeit von Teams wichtig. In klassischem Vorgehen und personenabhängiger Stunden- oder Tage-Schätzung gibt es in einem guten Fall nach geraumer Zeit ein Gefühl für die Aufwände des einen Entwicklers. Die Aufwände sind aber individuell von den Personen abhängig und lassen sich nicht für ein Team hochrechnen und es bleibt bei einem Gefühl und keiner gemessenen Größe. Wenn man weiß, dass ein Entwickler sich immer um 50% verschätzt, können seine individuellen Aufwände für die Planung verdoppelt werden. Wenn ein anderer immer 100% mehr Aufwand plant, als er braucht, kann auch das in der Planung berücksichtigt werden. Wie aber gehe ich damit um, wenn ich gar nicht genau weiß, wer von den beiden was umsetzen wird?
Zu 4) Der entscheidende Punkt: Mit Storypoints rückt die Vergleichbarkeit der Aufwände zwischen einzelner Stories stärker in den Vordergrund und es fällt leichter, Aufwände und Business-Wert zu vergleichen. Die Frage ist also weniger, ob eine Story den geschätzten Aufwand für sich gesehen Wert ist, sondern ob unter Berücksichtigung des Business-Werts der Aufwand einer Story im Verhältnis steht zu Business-Wert und Aufwand einer anderen Story. Product Owner können so einfacher Prioritäten festlegen oder ändern. Die Diskussion dreht sich um die Frage, ob eine Aufgabe, die beispielsweise doppelt so viele Storypoints wie eine andere Story hat, auch den doppelten oder eher einen niedrigeren oder gar noch höheren Businesswert hat und damit vielleicht wichtiger oder unwichtiger für das Gesamtprojekt wird.
Nachsatz: Es ist übrigens durchaus sinnvoll, Schätzung nach Storypoints in der Fibonacci-Reihe zu machen, da die schätzenden Personen durch die nicht lineare Reihe der möglichen Schätzwerte gezwungen sind, grobe Aufwandsabschätzungen zu machen und Komplexitäten gegeneinander abzuwägen.
Mehr dazu kann man unter anderem in einem Blog-Beitrag von Jeff Sutherland nachlesen.
