Vielleicht hast du bereits von Story Points gehört oder Story Points eingesetzt.
Agile Teams können mit Story Points Aufwände schnell einschätzen. Wenn Story Points korrekt angewendet werden. In diesem Artikel erkläre ich dir, was Story Points sind und wie du und dein Team Story Points richtig anwenden.
Selbst, wenn unterschiedlichste Rollen in einem Team vertreten sind, ist eine gemeinsame sinnvolle Schätzung möglich.
Oftmals scheitert das Story Points schätzen, weil das Verständnis von Story Points und der Umgang mit ihnen fehlt.
Story Points schätzen habe ich nicht erfunden
Von vielen kompetenten Menschen durfte ich fundamentale Methoden und Konzepte lernen.
Besonders beeinflusst haben mich Kent Beck, Alistair Cockburn, Mike Cohn, Tom DeMarco, Robert C. Martin, Jeff Patton, Tom und Mary Poppendieck, Ken Schwaber und viele andere.
Einige Konzepte und Methoden passte ich über die Jahre, für meine Tätigkeit in mehr als 50 Organisationen an.
Die von mir besprochenen Lösungen sind das empirisch gewonnene Produkt aus Wissen mal Erfahrung.
Abweichungen zur reinen Theorie sind möglich und natürlich gewünscht.
Warum mit Story Points schätzen?
Bei meinen Kunden erlebe ich immer wieder, dass insbesondere Scrum Teams keinen vernünftigen Weg zum Schätzen von User Storys finden.
Sie finden keine Lösung und streiten darüber, wie viele “tatsächliche” Story Points eine User-Story hat.
Das ist völlig normal.
Unterschiedliche Skills und Erfahrungen der Developer führen zu verschiedenen Sichtweisen.
Ein Anfänger wird höhere Story Points schätzen, als ein alter Hase mit viel Erfahrung.
Ein Backend-Developer wird eine andere Menge Story Points schätzen als ein Tester, selbst dann, wenn beide die gleiche Berufserfahrung haben.
Sind Story Points Zeit?
In den schlimmsten Fällen werden Story Points als Umschreibung für Zeit missbraucht.
Manche Teams bestehen sogar darauf, das zu tun.
So wird zum Beispiel 1 Story Point mit 8 Stunden Entwicklungsaufwand gleichgesetzt.
Das führt unweigerlich zu handfesten Problemen. Das Team streitet und diskutiert über die richtige Anzahl Story Points.
Diskussionen wie: Es dauert 3 Story Points, wenn du das machst und 5 Story Points, wenn ich das mache.
Das kann zu keinem Ergebnis führen!
Oft erlebe ich, dass Kompromisse eingegangen werden.
Developer, die zum Beispiel 5 und 13 Story Points schätzen, einigen sich gerne auf 8 Story Points. Story Points sollen aber unabhängig von der Person sein, die die Arbeit ausführt.
Andere Teams schätzen Komplexitäts-Punkte, weil die User Storys unterschiedlich “komplex” sind.
Komplexität beschreibt die Menge der Eigenschaften, die Einfluss auf Interaktionen hat.
Der Fehler dabei ist: Menschen können sich Komplexität gar nicht vorstellen.
Menschen denken in Aufwand, um eine Arbeit zu erledigen.
Ich kenne Scrum Master, die Entscheidungsbäume und Fragenkataloge erstellen, damit Teams Komplexität schätzen können.
Das ist wirklich schrecklich und dem fundamental fehlenden Verständnis vom Story Point schätzen zuzuschreiben.
Was Story Points tatsächlich sind
Du weißt bereits, dass es eine wirklich üble Idee ist, Story Points mit x Stunden von Zeit zu definieren.
Wie lassen sich Story Points richtig beschreiben?
Betrachte Story Points als relatives, abstraktes Maß für Aufwand.
Betrachten wir die Begriffe: Relativ, Abstrakt und Aufwand etwas genauer.
Abstrakt beschreibt die Unmöglichkeit, mit Story Points objektiv etwas zu messen.
Nehmen wir an, Story Points haben ein Gewicht.
Du kannst kein geschätztes Backlog an eine Skala legen und wiegen.
Selbst wenn du es könntest, dann würde dieses Backlog in jedem Team auf diesem Planeten ein anderes Gewicht aufweisen.
Es gibt keine Skala um Story Points schätzen zu können
Du kannst einen Liter Wasser wiegen.
Es wiegt ein Kilogramm, unabhängig davon, welches Team den Liter Wasser wiegt.
Das ist der Grund, warum Story Points, im Gegensatz zu Litern und Kilogramm, abstrakt sind.
Wie lassen sich abstrakte Story Points eine Bedeutung zuordnen?
Story Points bekommen eine Bedeutung, wenn du sie in Relation zueinander setzt: Eine User-Story mit 2 Story Points hat den doppelten Aufwand wie eine 1 Story Point User Story und eine 40 Point User Story verursacht den doppelten Aufwand einer 20 Point User Story.
User Storys mit Story Points schätzen ergibt erst dann einen Sinn, wenn du sie in Relation zu anderen User Storys setzt.
Dabei sind die Zahlenwerte vollkommen unwichtig.
Es zählt nur das relative Verhältnis der Zahlenwerte zwischen User Storys.
Eine User-Story, die doppelt so viel Aufwand verursacht, hat den doppelten Zahlenwert.
Es spielt keine Rolle, ob das Team 1 und 2, 10 und 20 oder 245 und 490 verwendet.
Story Points beziehen sich immer auf die individuell angewendete Skala.
Story Points sind additiv.
Zwei 2 Point Storys sind so viel Aufwand wie eine 4 Point Story oder zwei 4 Point Storys entsprechen dem Aufwand einer 8 Point User Story.
Kommen wir zum Aufwand der relativ abstrakten Story Points.
Aufwand ist Zeit.
Es ist die Dauer, in der die Arbeit erledigt werden kann.
Vielleicht hast du gehört, dass Story Points nichts mit Zeit zu tun haben.
Das ist falsch! Glaub mir, Story Points sind untrennbar mit der Zeit verbunden.
Die Stakeholder wollen wissen, wann das Produkt fertig ist oder wie viel bis zu einem definierten Datum geliefert wird.
Dafür muss geschätzt werden, wie viel Zeit es braucht, um die Arbeiten zu erledigen.
Das ist, was dein Chef, die Kunden oder Nutzer benötigen.
Allerdings ist es nicht möglich, mit dem Begriff Zeit so umzugehen, wie wir es bisher getan haben.
Story Points sind relative Zeit – Ein Beispiel
Stell dir vor, zwei Bauarbeiter müssen Sand in Schubkarren schaufeln.
Der eine Bauarbeiter ist kräftig und gut trainiert.
Der andere ist schmächtig und hat den Job gerade erst angefangen.
Die Bauarbeiter stehen also vor dem Sandhaufen und der kräftige Bauarbeiter sagt: “Das dauert eine Stunde”.
Der schmächtige Bauarbeiter erwidert: “Auf keinen Fall, das dauert 2 Stunden.”
Hier liegt das Problem bei dem schätzen in Zeit!
Beide Bauarbeiter haben für sich genommen recht.
Damit sind sie nicht in der Lage, eine gemeinsame Schätzung abzugeben.
Jeder beharrt auf seiner eigenen Schätzung und es beginnt eine Diskussion, die nicht gewonnen werden kann.
Vielleicht kommen die Bauarbeiter auf die Idee einen Kompromiss einzugehen und sagen: “Ok, es dauert 1,5 Stunden.”
Ein Kompromiss, ist vermutlich die schlechteste Idee von allen.
Die Bauarbeiter geben eine Schätzung ab, die für beide falsch ist.
Das machen auch Teams, wenn sie in Zeit schätzen.
Frage ein Team, wie lange die Bearbeitung einer Aufgabe dauert und du erhältst unterschiedliche Schätzungen auf Basis persönlicher Erfahrungen und Fähigkeiten der einzelnen Teammitglieder.
Am Ende kommt, wie bei den Bauarbeitern, ein Kompromiss heraus.
Story Points lösen dieses Problem, weil sie relativ und abstrakt sind.
Der kräftige Bauarbeiter könnte ganz zu Beginn sagen: “Diesen Haufen wegschaufeln, dauert doppelt so lang, wie bei dem von gestern”.
Der schmächtige Bauarbeiter kann dem zustimmen.
Die Bauarbeiter können sich nicht auf eine Zeit in Minuten, Stunden oder Tagen einigen.
Mit Relationen können Sie sich darauf einigen, dass sie halb, doppelt oder dreimal so lang zum Wegschaufeln brauchen, wie einen anderen Sandhaufen.
Story Points sind relativer Aufwand
Beim Story Points schätzen ist es möglich, mit unterschiedlichen Erfahrungen und Fähigkeiten, sich auf einen relativen Aufwand zu verständigen.
Jedoch unmöglich, wenn Teammitglieder Aufwand in Stunden, Tagen schätzen.
Story Points beziehen sich auf Aufwand.
Aufwand wird als Menge von Zeiteinheiten definiert, die zum Bearbeiten einer Aufgabe nötig ist.
Wenn alle Teammitglieder gleich schnell arbeiten, können wir Zeiteinheiten in Stunden, Tagen oder Wochen oder was immer du willst, definieren.
Teammitglieder sind aber nicht konsistent in der Arbeitsgeschwindigkeit.
Du erledigst bestimmte Arten von Arbeit schneller als ich und ich erledige andere Arten von Arbeit, schneller als du.
Deshalb können wir uns nicht auf eine explizite Dauer festlegen.
Wir können uns aber darauf einigen, dass eine Arbeit doppelt so lange dauert wie eine andere Arbeit.
Wir einigen uns auf das Verhältnis zueinander – den relativen Aufwand.
Weil es Menschen nicht möglich in etwas anderes zu schätzen als in Zeit, bedienen wir uns eines Tricks.
Beim User Story schätzen, denken wir in Zeit und sprechen relativ.
Wie bei den Bauarbeitern.
Der eine Bauarbeiter denkt eine Stunde, der andere denkt 2 Stunden. Das ist in Ordnung.
Wenn aber jeder sagt, was er denkt, geraten wir in eine endlose Diskussion, die niemand gewinnen kann.
Jeder hat aus seiner Sicht recht.
Denkt der kräftige Bauarbeiter eine Stunde, die das Wegschaufeln des Sandhaufens dauert und sagt “halb so lang wie ein anderer Sandhaufen”, kann der schmächtige Bauarbeiter zustimmen, weil er an 2 Stunden denkt.
In Zeit denken und relativ argumentieren
Wichtig ist, dass die Schätzer beim User Story schätzen, in Zeit denken, aber in relativ abstrakten Aufwand sprechen.
In Story Points.
Ist dieses Verständnis in den Scrum Teams nicht vorhanden, dauern die Estimations um ein Vielfaches länger als tatsächlich notwendig.
Das führt zu Frustration und Sätzen wie: “Das dauert X Story Points, wenn du es tust, aber Y Story Points, wenn ich es tue.”
Immer dann, wenn du die beiden Fälle in Estimations erlebst, ist das ein sicheres Signal dafür, dass Story Points und das Story Points schätzen, fundamental missverstanden werden.
So löst du das Story Point Problem im Team
Alles auf Anfang.
Erkläre dem Team wie und warum relativer abstrakter Aufwand zu schätzen ist.
Nutze dafür diese Anleitung.
Frage relative Fragen während des Story Points schätzen wie: “Wie viel Aufwand beinhaltet diese Story im Vergleich zu einer anderen.”.
Das hilft auch dann, wenn die Teammitglieder deiner Erklärung zu Story Points nicht folgen wollen.
Triangulation.
Setze eine neu zu schätzende User Story ins relative Verhältnis zu zwei anderen User Storys.
Wähle die bekannten Storys so, dass diese vom Aufwand her, weit genug auseinander liegen.
So kann das Team besser einordnen, ob die neu zu schätzende User Story in die Mitte oder mehr zu der einen oder anderen Seite tendiert.
Fazit
Mit diesen einfachen Methoden kannst du Teams anleiten, beim Story Points schätzen eine hohe Geschwindigkeit zu erreichen.
Was du damit nicht verhindern kannst, ist der Druck der Stakeholder exakte oder perfekte Schätzungen abzuliefern.
Dieser Druck kann dazu führen, dass die Teams beim Story Points schätzen, nicht mehr vorankommen und keine Lust mehr auf Schätzungen haben.
Sei erfolgreich, bleib erfolgreich.
Frank Schatz,
damit es agil wird.
Quellen:
-
Ron Jeffries, 2019, Story Points revisited
-
Fibonacci-Folge, Wikipedia
-
Mike Cohn, Mountain Goat Software
-
Wikipedia, Weber-Fechner-Gesetz
