Startseite » Story Points

Story Points

Zentrale Fragen in jedem Projekt sind immer wieder:

  • Wann bekomme ich es?
  • Was kostet es?

Gleichzeitig wissen wir, dass die Antworten oft maximal schlecht sind. Wir bewegen uns in komplexen Umgebungen und können genau das nicht gut beantworten. Statistiken zeigen, dass die Mehrzahl der Projekte als „gescheitert“ definiert wird, weil sie entweder das Budget gerissen, die Ziele nicht erreicht oder Termine verpasst haben. Also: Wir können bei innovativen Vorhaben nicht gut schätzen.

Nun haben sich in der agilen Welt „Story Points“ herauskristallisiert. Story Points in Scrum oder aber auch in anderen Methoden. Hier sind 2 Aspekte wichtig:

  1. Story“ – darin steckt nicht wirklich eine Geschichte, sondern der Fokus auf dem was erreicht werden soll (nicht gemacht werden soll)
  2. Points“ – es gibt ein subjektives aber relatives Punktesystem, um sich von der scheinbaren Sicherheit in Stunden, Tagen oder Wochen zu lösen
Story Points ScrumPin
Story Points schätzen in Scrum

Story Points frei von Zeitschätzungen

Idealismus trifft auf Realität: die Story Points im Lehrbuch beschreiben die Komplexität von etwas. Ist sonnenklar, was umgesetzt werden muss, dann ist es eine „1“ (also sehr klein). Ist eine Sache unklarer bis hin zu vollkommen nebelig, dann ist es eine hohe Zahl „21“, „42“. Das macht theoretisch Sinn, denn viel Unklarheit bedeutet auch oft viel Unwägbarkeit. Damit haben wir ein Maß für Stories bezogen auf die Unwägbarkeit, Hürden, die Auftreten können. Das hilft auch sehr weiter bei der Bewertung, ob eine Story besser noch in kleinere Teile unterteilt werden sollte – falls möglich.

Gleichzeitig sitzt das Team zur Planung der nächsten Zeit zusammen (z.B. Sprint Planning im Scrum  für 2 Wochen) und möchte sich auf Stories bekennen (Neudeutsch: commiten), die es dann auch liefert. Z.B. 2 Wochen, 5 Kollegen, ein paar Meetings und ein Urlaub – da ist der Faktor Zeit dann doch schnell wieder in den Hinterköpfen.

Ein kleines Beispiel:

Wenn ich einen LKW mit 2000 Kartons ausladen soll und die Kartons in einem Lagerraum staple, ist die Komplexität quasi null => Schätzung „1“. Ich weiß genau, was ich machen muss. Gleichzeitig nimmt diese komplexitätsfreie Fließbandarbeit vermutlich viel Zeit in Anspruch. Ich kann mir also nicht sehr viele dieser „1er“ Stories für den Sprint mitnehmen.

Es geht also am Ende darum beides einfließen zu lassen: Unwägbarkeit und Zeitaufwand. Dann können sie hilfreich sein.

Wann funktionieren Story Points?

Das allerwichtigste bei der Verwendung von Story Points ist:

Story Points sind vom Team gemacht und für das Team gemacht. Sie scheitern, wenn sie ein Controlling Instrument für das Management werden.Click to Tweet

Story Points helfen dem Team sich selbst zu orientieren. Nach einem Sprint oder beliebigen Zeitraum kann sich das Team fragen:

  • Bei welchen Stories lagen wir daneben und weshalb?
  • Gibt es Parallelen und was lernen wir daraus?
  • Wie entwickelt sich unsere Lieferung von Story Points?

Team Velocity aus Story Points

Über einen Zeitraum entsteht dann ein gemeinsames Verständnis zu Story Points, eine kontinuierliche Verbesserung und was aus meiner Sicht für das Unternehmen das Wichtigste ist: eine konstante Lieferung und damit Planbarkeit (das nennt sich Team Velocity – die Team-Geschwindigkeit). Die Velocity ist Team spezifisch. Es kann sein, dass sich im Nachbarteam ein ganz anderes Verständnis zu Story Points entwickelt hat und damit die Team Velocity einen ganz anderen Zahlenwert bekommt: nicht vergleichbar.

Wenn Story Points als Maß für die Leistung des Teams herangezogen werden – also ein Kontrollinstrument, dann wird es oft zu einem Schildbürgerstreich. Die Team-Mitglieder stellen sicher, dass die Stories immer etwas grösser geschätzt werden und damit die gelieferten Story Points immer kontinuierlich mehr werden. Das habe ich mehrfach erlebt und ich hätte in keinem Fall Absicht unterstellt, vermutlich ein unterbewusster Mechanismus.

Vielleicht erwähnenswert, vielleicht schon klar: die Art und Weise der Story Point Schätzung als auch der Verbesserung der Team Velocity ist gut platziert in der Team Retrospektive.

Kleine Randnotiz: Ich bin grundsätzlich der Meinung, dass KPI immer da wo sie erzeugt werden in der Arbeit helfen sollten. Kennzahlen, die nur dem Reporting helfen, sollten nicht erhoben werden.

Story Points für den Product Owner

Nun habe ich oben geschrieben “Story Points seien vom Team und für das Team“ und nun sind sie für den Product Owner? Ja, für den Product Owner sind sie in zwei Anwendungsfällen:

  1. Es ist für den PO wichtig zu sehen, welche Stories hohe Points haben (die Nähe von Story Points zu Produktionskosten ist ja nicht zu leugnen). Das in der Kombination mit Business Value einer Story, macht ja quasi eine „automatische“ Priorisierung.
  2. Wenn das Team halbwegs eingeschwungen ist und eine ungefähr konstante Zahl an Story Points liefert, sind sie eine tolle Planungsgrundlage für das Backlog. Im Backlog haben die nächsten, wichtigsten Stories alle einen Business Value und Story Points. Jetzt kenne ich ungefähr die Zahl der Story Points pro Zeiteinheit, die das Team schafft. Damit kann ich ungefähr kennzeichnen, wo wir pro Monat in der Umsetzung des Backlogs landen werden – quasi eine grobe Roadmap. (Achtung: wir sind in der agilen Welt, es werden neue, wichtige Stories erfunden, das Backlog ist in Bewegung)

Der Product Owner kann Story Points für die Planung nutzen und erkennen, welche Stories noch zu groß sind. Auch können hohe Zahlen einen Impuls für die Beratung des PO durch das Team geben: „Was macht diese Story so teuer? Gäbe es Kompromisse, die sie günstiger machen?“ Die Zahlen an sich sind nicht sein „Geschäft“.

Story Points schätzen

Hierzu habe ich zwei Methoden zusammengestellt:

  1. Die wohl bekannteste Methode: Planning Poker
  2. Eine nette Methode auch große Mengen zu schätzen: Magic Estimation
  3. Eine schnelle Methode: Thumbs up oder Fist of Five

Sehr eingespielte Teams schaffen es aber auch sich Story Points zuzuwerfen und finden dann in wenigen Sätzen eine gemeinsame Zahl. Dahin ist aber ein Weg zu gehen, von daher ist es ratsam zunächst eines der etablierten Formate zu wählen.

Weiterführende Artikel


Schreibe einen Kommentar

Neues per E-Mail?

Synapsenstau.deAgile Business Development. Agile Transformation. hat 4,78 von 5 Sternen11 Bewertungen auf ProvenExpert.com