Story Points: In den richtigen Händen, ein machtvolles Konzept.

Teile diesen Beitrag mit deinen Freunden!

Sind Story Points ein Maß für die Komplexität, Aufwand, verschleierte Stunden oder was steckt dahinter? Die Mächtigkeit von Ron Jeffries´ Story Points und der Versuch einer Definition.

Diese Einflussfaktoren (und weitere) wirken in eine Richtung und erhöhen das Risiko im Erreichen des Sprintziels: Der fertigen Umsetzung der User Story.

 

Daher lautet meine Definition von Story Points:

„Story Points beschreiben die Größe des Risikos der Realisierung einer User Story.“

Ich habe aus diesen Gründen den zeitlichen Aufwand bei meiner Definition herausgenommen:

  1. Verhältnis von Aufwand und Nutzen:
    Die Schätzung in Story Points sollte schnell durchführbar sein. Wenn ein DevTeam[1] sich mit dem zeitlichen Aufwand (Personentage oder Stunden) der Realisierung auseinandersetzen soll, erscheint mir eine zügige Schätzung nicht mehr möglich. Vom DevTeam wird in diesem Moment eine verlässliche Vorhersage(!) eingefordert, die sofort für Unsicherheit und Zurückhaltung sorgt und den Aufwand für die Schätzung nach oben treibt. Das DevTeam wird möglichst viele Unsicherheiten im Vorfeld einer Aussage beseitigen wollen und wahrscheinlich noch einen Zeitpuffer miteinrechnen, um bei der Umsetzung nicht in Zeitnot zu geraten. Eine Schätzung nach Aufwand erhöht den Aufwand für die Schätzung.Es passiert in diesem Moment aber noch mehr:
    Es entsteht psychologischer Druck im DevTeam, ja bloß in der veranschlagten Zeit zu liefern. Die Lockerheit und Unverkrampftheit bei der Realisierung kann dadurch beeinträchtigt werden. Eine einfachere Lösung wird unter Umständen vom DevTeam nicht gesehen, da es sich zu schnell auf eine Richtung festgelegt hat. Ggfs. werden sogar Abstriche in der Qualität oder in der Flexibilität der Architektur in Kauf genommen.
    Es manifestiert sich wieder einmal die offenbar vorhandene Erwartungshaltung an die Orakelfähigkeiten des DevTeams. Dies entfernt Aussenstehende weiter vom DevTeam und vom Verständnis der Arbeit, die das DevTeam zu tun im Stande ist.Eine wirklich belastbare Aussage zum Aufwand kann nur rückwirkend erfolgen, wenn die Realisierung abgeschlossen ist und die dafür benötigten Stunden bekannt sind. Dies hat aber für mich nichts mit einer Schätzung zu Beginn der Entwicklung zu tun, die eine Prognose über die Anzahl der benötigten Entwicklungszyklen liefern soll.
  1. Chance zur Verbesserung:
    Wenn ein DevTeam in die Situation gerät, dass für eine Story mit geringem Risiko in der Implementierung eine hohe Anzahl von Stunden erforderlich waren, kann das DevTeam in der Retrospektive überlegen, wie dieser hohe Aufwand in Zukunft vermieden werden kann. Wenn eine Lösung gefunden ist, führt dies zu einer Verbesserung im „System“. Ein DevTeam hingegen, welches für diese Story den hohen Aufwand direkt in Story Points ausdrückt, umgeht die Herausforderung und verpasst eine Chance zur Verbesserung, das das Missverhältnis von Story Points und Stunden nicht erkennbar ist.

 

Auch wenn Ron Jeffries und seine Leute damals (siehe unten) in erster Linie eine Möglichkeit gesucht haben, um mit penetranten Managern umzugehen und diesen keine Gelegenheit geben wollten, sie auf Personentage oder Stunden festzunageln, so haben Story Points weitaus mehr Potential. Entsprechend verwendet, trennen sie die Risikobewertung vom Aufwand der Realisierung und öffnen den Weg zu Verbesserungen im System.

 

Zwei Zitate von Ron Jeffries aus dem Jahr 2011 und 2015:

„When we invented Story Points, we had in mind simply „how long will it take to do this story. (…)  Story points were invented for political reasons: At the time we invented story points, the team in question had been estimating in „Ideal Time“, the time it would take to do the story if not interrupted. (…) Ideal Time was supposed to be a new kind of unit that didn’t have that promissory aspect. (…) Story Points were invented to obfuscate duration so that certain managers would not pressure the team over estimates.“ [2]

„Als wir Story Points erfunden haben, hatten wir uns einfach nur gedacht: „Wie lange wird es dauern, um diese Story zu machen?“(…) Story Points wurden aus politischen Gründen erfunden: Zu der Zeit, in der wir Story Points erfunden haben, schätzte besagtes Team nach „Idealer Zeit“, die Zeit, die es dauern würde, um die Story um zusetzen, wenn es keine Unterbrechungen geben würde. (…) Ideale Zeit sollte eine neue Art von Einheit sein, die den Anschein einer Zusage [Richtung Mangagement, d.Ü.] nicht hatte. (…) Story Points wurden erfunden, um die Dauer verschleiern, so dass bestimmte Manager das Team nicht wegen abgegebener Schätzungen bedrängen würden.“

„The idea with story estimation is that you figure out (…) how “big” each story is.“ [3]

 

Siehe auch meinen Blogpost
https://cmmann.de/ueber-die-vorteile-der-trennung-von-story-points-und-zeitlichem-aufwand/

 

[1] DevTeam: Alle, die am Sprintbacklog mitarbeiten.

[2] https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/scrumalliance/story$20points$20were$20invented/scrumalliance/ag8W8xtKQs8/Sh-jYHmQrd8J

[3] http://ronjeffries.com/articles/015-jul/what-estimates-are-not/

Teile diesen Beitrag mit deinen Freunden!

Schreibe einen Kommentar

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