Normalisierte Story Points in SAFe – wie und warum?

SAFe4 schlägt vor, dass Story Points innerhalb der Produktentwicklung über die verschiedenen Teams hinweg standardisiert sein sollten. Dazu bietet SAFe eine Methode an, wie man im allerersten Sprint bereits Story Points schätzen kann. Aus Sicht von Scrum erscheint diese Herangehensweise zunächst inkonsistent mit der Idee von Story Points. Um diesen Widerspruch aufzulösen, schauen wir uns die Idee etwas näher an.

Was sind überhaupt Story Points?

Story Points sind, kurz gesagt, ein willkürliches Maß zur Quantifizierung des Aufwands eines Backlog Items. Sie sollen den Entwicklern helfen, ihre Kapazität besser zu planen – und dem Product Owner, ein Verständnis zu bekommen, was in den kommenden Wochen und Monaten erreichbar ist. So lassen sich beispielsweise Termine und Lieferumfang eines Releases vorhersagen.

Ein zusätzlicher Nutzen wird von Mike Cohn vorgeschlagen: Wenn die Velocity und monatlichen Kosten eines Teams kennt, kann man Kostenschätzungen für Backlog-Items betreiben. So lässt sich die Wirtschaftlichkeit der Entwicklung optimieren. Beispielsweise kann ein Backlog-Item unwirtschaftlich erscheinen, sobald die Kosten bekannt sind. So kann der Product Owner frühzeitig entscheiden, ob eine Story umgearbeitet oder komplett verworfen wird.

SAFe greift diese Idee im WSJF Konzept auf: Features mit der besten Kosten-Nutzen-Relation sollten bevorzugt werden.

Das Wichtigste, damit so eine Herangehensweise funktionieren kann, ist, dass alle Beteiligten ein gleiches Verständnis von Story Points haben. Weil Story Points für unterschiedliche Teams durchaus etwas unterschiedliches bedeuten können, sollte man vorsichtig sein, wenn man die Werte außerhalb des Teams betrachtet.

Was sind Normalisierte Story Points?

In SAFe ist die Entwicklungseinheit für das Produkt ein Agile Release Train (ART), ein „Team of Teams„.

Genauso wichtig wie es in Scrum ist, dass alle Beteiligten im Team einen Story Point gleich verstehen, ist es in SAFe, dass alle Beteiligten im ART einen Story Point gleich verstehen.

Würden Teams Story Points unterschiedlich interpretieren, würde der Produkt-Manager vollkommen unterschiedliche Schätzungen bekommen, je nach dem welches Team ein Item geschätzt hat. Die so entstehenden Schätzungen wären aus Business-Sicht komplett unbrauchbar. Damit wäre der gesamte Schätzprozess nutzlos und die Schätzungen wertlos.

Darum schlägt SAFe vor, dass genau so wie im Scrum Team ein gemeinsames Verständnis von Story Points benötigt wird, auch die einzelnen Teams im ART ein gemeinsames Verständnis von Story Points benötigen, um sinnvoll zu schätzen.

Warum sind individuelle Story Points pro Team keine gute Idee?

In SAFe teilen sich alle Teams im ART ein einziges, gemeinsames, zentrales Program Backlog. Dieses Program Backlog konsolidiert sämtliche Tätigkeiten des ART, unabhängig davon, welches Team die Arbeit tatsächlich später übernimmt.

Ein Schlüsselkonzept der Agilität ist, dass Arbeit unabhängig von der Person sein sollte, denn Spezialisierung führt zu lokaler Optimierung.

Aus Lean-Sicht ist es oftmals besser, wenn ein langsameres Team sofort mit der Arbeit beginnt, statt dass man mit wichtigen Dingen auf das schnellere Team wartet.

Besonders dann, wenn mehrere Teams zusammenarbeiten, kann ein langsameres Team oft schon einen Teil des Wertes liefern, bevor das schnellere Team verfügbar wird, um sich zu beteiligen. So reduziert sich die Gesamtzeit der Lieferung und die Bindung des schnelleren Teams bis zur endgültigen Fertigstellung.

Wenn Story Points zwischen Teams unterschiedlich sind, muss jedes einzelne Backlog Item von jedem einzelnen Team geschätzt werden, bis man versteht, welches Team wann fertig sein könnte. Das ist natürlich möglich, bedeutet jedoch massiv Vergeudung und Overhead.

Sind hingegen die Story Points über Teams hinweg normalisiert, braucht man nur eine einzige Schätzung von einem einzigen Team. Betrachtet man dann die Velocity der einzelnen Teams, sieht man schnell und einfach, wie lange es dauern würde.

Ein zusätzlicher Nutzen normalisierter Story Points ist: Braucht Team A die Unterstützung von Team B, um eine wichtige Deadline zu erreichen, weiß der Product Owner von Team B sofort, wie viel Team B aus seinem Backlog heraus streichen müsste, um die Stories von Team A zu übernehmen: Da keine Neuschätzung benötigt wird, entstehen weder Verzögerungen noch Aufwände für Schätzung.

Wie genau normalisiert SAFe die Story Points?

Im allerersten Program Increment ist der ART neu. Weder die einzelnen Teams, noch die Personen im ART, haben jemals in exakt dieser Konstellation gearbeitet. Die Teams befinden sich in der „Storming Phase“ – wie auch der ART selbst.

Das wiederum bedeutet: die Working Agreements sind noch unklar. Die DoD ist ein schwammiges Ideal, welches noch nie in der Praxis erprobt wurde. Überall können Stolpersteine liegen. Je nach dem, wie die Produktentwicklung läuft, ist wohl auch die Arbeitsumgebung neu und unbekannt. Alle befinden sich auf einem weißen Fleck in der Landkarte – jede Schätzung ist Kaffeesatzleserei.

Ein möglicher Ansatz wäre jetzt, dass man gemeinsam darüber diskutiert, welche Story man als Referenz auswählt, wie man Punkte definiert, welche Punkte die Referenz-Story bekommt – und dann arbeitet man von dort aus. Diese Diskussion wird zu weiteren Diskussionen führen, welche alle in sich keinen Wert aus Kundensicht darstellen.

SAFe vermeidet dieses Vorgehen und schlägt folgendes vor: Relativ Schätzen

Im allerersten PI Planning beginnt man damit, dass das Team das kleinste Item aus seinem Backlog auswählt und diesem eine „1“ zuweist. Dem nächstgrößeren Item weist man eine „2“ zu, und hangelt sich unter Nutzung einer an die Fibonacci-Zahlen angelehnten Reihe (1,2,3,5,8,13,20,40,100) vorwärts: Haben wir ein Item der gleichen Größe wie ein bekanntes Item? Wenn ja, kriegt es die gleiche Zahl – wenn es das bisher größte ist, bekommt es eine passende Zahl. Wenn wir keine gute Referenz haben und springen müssen, wäre „3“ mindestens doppelt so groß wie „1“, und „8“ mindestens doppelt so groß wie „3“ etc. So lässt sich über ein sehr einfaches Vorgehen ohne genaues Wissen eine Einschätzung bilden, was das Team vor sich hat.

Das ist natürlich pures Raten und die Werte sind recht unscharf. Aber da wir noch keine Erfahrungswerte haben, ist dieses Vorgehen so gut wie jedes andere. Das Wichtigste ist, dass die Teams bei den Stories über „Was“, „Warum“ und potentielle Risiken diskutieren.

Wie berechnet sich Velocity über Normalisierte Story Points?

Um es noch einmal zu betonen: im ersten Program Inkrement haben wir keinerlei Ahnung, wie viele Story Points ein Team tatsächlich schafft. Da wir jedoch PT-Schätzungen haben, schlägt SAFe folgendes Vorgehen im ersten PI-Planning vor:

Wir wissen, wie viele Teammitglieder unser Team hat. Wir wissen auch, an wie vielen Tagen wir in einer Iteration vorhaben, zur Arbeit zu kommen (natürlich weiß man nicht, wann man krank wird – das Risiko bleibt einfach).

Eine übliche SAFe-Iteration dauert 2 Kalenderwochen, hat also 10 Arbeitstage. Diese Zahl kann man it der Anzahl Teammitglieder multiplizieren:
Base Capacity = 10 * Team Members

Davon ziehen wir dann die Tage ab, an denen Teammitglieder nicht anwesend sind:
Angepasste Capacity = Base Capacity – (Feiertage * Team Members) – (einzelne Abwesenheitstage)

Davon ziehen wir noch mal 20 Prozent ab – denn die Planung auf 100 Prozent Auslastung führt immer zum Disaster!
Initiale Velocity = Angepasste Capacity * 0.8

Hier ein Beispiel:
Team Trolls besteht aus 6 Entwicklern. Es gibt in der nächsten Iteration einen Feiertag und Toni muss am Freitag was Privates erledigen.

Base Capacity = 106 = 60 SP
Angepasste Capacity = 60 SP (Base) – 16 SP (Feiertage) – 1 SP (Abwesenheit) = 53 SP
Initiale Velocity = 53 SP * 80 Prozent = 42 SP

Team Trolls würde dann die Iteration 1 mit 42 Story Points beplanen. Wenn die Zahlen der Stories nicht ganz passen, ist es immer besser, ein bisschen darunter zu bleiben, als sich zu übernehmen. Die Trolls könnten daher entscheiden mit 39 SP’s in die erste Iteration zu gehen.

Was passiert über Zeit mit den Normalisierten Story Points?

In der ersten Iteration haben wir einfach mal geraten. Raten ist besser als nichts. Und danach greift Inspect+Adapt. Vielleicht haben die Trolle gelernt, dass sie sich durchs Backlog fräsen wie ein heißes Messer durch Butter. Sie würden dann natürlich nächstes Mal ein paar Story Points mehr nehmen. Vielleicht haben die Badgers gelernt, dass sie viel für andere Teams tun müssen (wie zum Beispiel Wissenstransfer). Sie würden dann in Zukunft nicht mehr so viele Story Points übernehmen.

So könnte sich die ART-Velocity über Zeit entwicklen:

Wie wir in diesem Beispiel sehen, nutzen Teams individuelles Inspect+Adapt und kontrollieren ihre eigene Velocity. Der Product Manager bekommt regelmäßig Feedback, um die Gesamtplanung des Produkts und die PI-Ziele (sowie ggf. Releaseziele) entsprechend anzupassen.

Neuschätzungen vormals geschätzter Backlog-Items entfällt. Wenn neue Themen bekannt werden, können „Done“ Stories als Referenz genutzt werden, um künftige Backlog-Items konsistent mit bestehenden und vergangenen Items zu schätzen. Die Kopplung zum Personentag verschwindet.

Vorsicht mit Normalisierten Story Points

Story Points sind keine Business-Metrik! Auch Velocity nicht. Sie sind vereinfachende Planungsmetriken, die den Aufwand der Planung minimieren und gleichzeitig hinreichende Zuversicht in die Machbarkeit geben.

Diese Metriken unterliegen im ART den gleichen Einschränkungen wie im Single-Team Scrum. Die folgenden Antipatterns müssen vermieden werden.

Auf keinen Fall darf man:

• Schätzungen als „korrekt“ ansehen. Es sind -und bleiben- Schätzungen.

• Fortschritt anhand „gelieferter Story Points“ messen. Nutzbare Produkte sind die primäre Fortschrittsmetrik!

• Teams anhand ihrer Velocity vergleichen. Velocity ist keine Performance-Metrik!

• Die Struktur des ART bezüglich der Velocity-Werte optimieren. Ein ART ist ein hochkomplexes adaptives System!

• Versuchen, Velocity konstant/steigend zu halten. Kapazitätsplanung ist Risikominimierung. Sie ist der Realität unterworfen. Velocity ist nur ein Indikator, der die Zuverlässigkeit der Planung erhöht!

Wann sollte man normalisierte Story Points anwenden?

Die Normalisierung von Story Points löst ein Problem, welches es ohne Skalierung überhaupt nicht gibt. Es beantwortet die Frage „Was passiert, wenn andere Teams an dieser Story arbeiten?“ Dazu muss das Verständnis eines Story Points über Teamgrenzen hinweg einheitlich sein.

So können im ART Backlog Items relativ leicht zwischen Teams hin- und hergeschoben werden, um statt der Auslastung einzelner Teams den Gesamtwert des gelieferten Produkts zu maximieren.

Bis bessere Informationen verfügbar sind, lässt sich mit einer sehr einfachen Benchmark und relativer Schätzung ein guter Überblick schaffen. Aus den fertiggestellten Storys können dann „passend geschätzte“, eingängliche Stories als Referenz für die Zukunft gewählt werden. Neuschätzungen gibt es nicht. Der initial einfach angenommene Zusammenhang zwischen Story Points und Personentagen verschwindet innerhalb kürzester Zeit. Das muss passieren, damit Story Points teamübergreifend konsistent bleiben.

Auch für die initiale Velocity-Planung nutzen wir in Abwesenheit besserer Informationen die sehr einfache Faustregel „80 Prozent der verfügbaren Zeit“. Sobald die erste Iteration abgeschlossen ist, nutzen wir das reale Ergebnis als Referenz für die Zukunft und passen uns adaptiv an. Innerhalb weniger Iterationen löst sich auch die Korrelation der Velocity zu zeitlicher Kapazität auf. Auch dies muss passieren, damit Velocity als Planungswerkzeug im ART konsistent und sinnvoll genutzt werden kann.

Im ART ist es noch schwieriger als im Single-team Scrum, der Versuchung zu widerstehen, Teams basierend auf Velocity zu bewerten. Der RTE hat die wichtige Aufgabe, die Integrität der Story Points zu gewährleisten, indem er sämtliche Versuche (üblicherweise seitens des Managements) unterbindet, welche die Story Points oder Velocity zweckentfremden würden.