Schätzen: Storypoints oder Stunden?

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?

  1. Storypoints beschreiben nicht den individuellen Aufwand einzelner Personen, sondern den Aufwand eines Teams.
  2. Storypoints unterliegen weniger kleinen Variationen in der Schätzung des Teams.
  3. Storypoints sind für ein konstantes Team eine dauerhafte Messgröße für die Entwicklungsgeschwindigkeit.
  4. 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.

5 Comments

Leave a Comment
  1. zu a)
    Auch die Kunden, mit denen ich zu tun hatte, haben bisher immer Aufwände in Form von Tagen haben wollen. Das lässt sich aber einfach abdecken, indem ich die Anzahl der Personen pro Sprint mit der geschafften durchschnittlichen Anzahl von SP pro Sprint verrechne. So weiß ich, wie viele Tage ich pro SP brauche und kann daraus ein Angebot entwickeln, mit dem Kunde, Vertrieb etc. zufrieden sind.

    zu b)
    Ich habe mit dem Team Estimation Game (http://www.inspectandadapt.de/alternative-schatzverfahren/) gute Erfahrungen gemacht in der Aufgabe, dass ein Team lernt mit der abstrakten Größe “SP” umzugehen. Noch dazu geht das recht schnell und macht Spaß – ist für den Anfang oder wenn es schnell gehen muss aus meiner Sicht besser als Planning Poker.

    Wenn ich mit einem neuen Team ein neues Projekt schätzen musste, dann haben wir die Stories in ein Backlog gepackt, das in eine Reihenfolge gebracht und dann die einzelnen Stories mit SP bewertet. Dann haben wir uns drei bis fünf Referenzstories in unterschiedlichen Größen und unterschiedlichem Bekanntheitsgrad ausgesucht, hier einen Task-Breakdown mit Aufwandsbewertung auf Stundenbasis gemacht, dann den daraus resultierenden Durchschnittsaufwand pro SP bestimmt und das auf das Projekt hochgerechnet um ein Angebot in konkreten “Aufwänden” abgeben zu können.

    Später haben wir die Schätzungen noch mit einem Konfidenzfaktor versehen (wie wohl fühle ich mich als Team mit meiner Schätzung) und dabei versucht, Stories mit einem niedrigen Konfidenzfaktor des Teams so zu bearbeiten (runter zu brechen, mehr Informationen zu beschaffen, technische Durchstiche zu machen), dass der Konfidenzfaktor nicht über einen bestimmten Wert ging.

  2. Hallo,

    eine gute Zusammenfassung – Danke dafür. Ist auch aktuell ein brennendes Thema!

    Der Sinn und Zweck von Story Points und Business Value sowie deren Vorteile ist mir absolut bewußt, leider konnte/durfte ich das im Rahmen der Kundenprojekte noch nie umsetzen, da
    a) Die Äußeren Umstände (Kunde, Vertrieb etc.) es nicht zulassen oder
    b) Die Mitarbeiter nicht zur Verfügung stehen, bzw. da erst deren “Mindset” in Richtung relative Schätzung geschärft werden muss

    Letzten Endes fehlt mir eine praktikable Lösung, wie man dem Kunden Story Points/Business Value verkauft im Sinne von €uros und auch noch eine grobe zeitliche Abschätzung liefert.
    Deswegen gehen sehr viele Unternehmen nach wie vor dazu über, die Groben Aufwändungen in Stunden bzw. PT zu schätzen um eine Zeitliche Kalkulation abzugeben.

    Wenn man mit Story Points vorher noch nie abgeschätzt hat, hat man natürlich auch keine Velocity, sprich die Pace, wie viele Story Points ein Team in einem Sprint von bspw. 3 Wochen schafft…. ein Henne – Ei Problem, oder?

    Viele Grüße,
    Damian

Schreibe deinen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert