Ich höre immer wieder Diskussionen über normalisierte Story Points in SAFe®. Die Leute sagen, dass normalisierte Story Points nicht agil sind, weil ein normalisierter Story Point einem idealen Personentag entspricht. Aber ist das wahr? Was ist überhaupt “normalisiert”? Und ist es in SAFe notwendig? Wir haben nachgeschaut. Und wir waren überrascht, was in SAFe wirklich steht. Oft passiert in der Praxis aber etwas ganz anderes.
SAFe® spricht von angeglichenen (annähernd normalisierten) Story Points.
SAFe verwendet den Begriff “normalisierte” Story Points. Die Artikel, die diesen Begriff nutzen, verweisen auf den Iteration Planning Artikel bezüglich der Definition von ‘normalisiert’. In diesem Artikel heißt es:
In der Statistik bedeutet “normalisiert”, dass Werte, die mit unterschiedlichen Skalen gemessen wurden, an eine gemeinsame Skala angepasst werden.
In der Statistik bezeichnet Normalisierung die Anpassung von Werten, die auf verschiedenen Skalen gemessen wurden, an eine gemeinsame Skala, oft um sie zu vergleichen oder zu kombinieren. Zum Beispiel können wir Testergebnisse aus verschiedenen Prüfungen normalisieren, damit wir sie direkt vergleichen können.
Weitere Informationen findest du im Wikipedia Artikel. Er erklärt “Normalisierung” im Bereich der Statistik.
In SAFe bedeutet “normalisiert”, dass Story Points auf unterschiedlichen Skalen von verschiedenen Teams an ein gemeinsames Verständnis von “einem” Story Point angepasst werden.
Die Definition von “Normalisierung” in der Statistik erklärt, was mit “normalisierten Story Points” in SAFe gemeint ist.
Wenn es mehrere Teams gibt, hat jedes Team seine eigene Story-Point-Skala. Normalisierung der Story Points bedeutet, dass die auf unterschiedlichen Skalen (von jedem Team) erfassten Story Points an eine gemeinsame Skala angepasst werden. Wenn wir dafür sorgen, dass die “1”-er Referenzstorys der verschiedenen Teams eine vergleichbare Größe haben, erhalten wir eine ungefähre gemeinsame Skala. In diesem Fall haben eine Story A der Größe “zwei” von einem Team und eine Story B der Größe “zwei” von einem anderen Team eine vergleichbare Größe.
Wichtig ist, dass auch bei angeglichenen Story Points jedes Team seine eigene Story Point-Skala hat. Die Skalen sind vergleichbar, aber nicht identisch. Deshalb nennt SAFe sie auch annähernd normalisiert.
Normalisierte Story Points bedeuten nicht, dass ein Story Point einem Tag Arbeit entspricht.
SAFe schlägt im Artikel Iteration Planning Artikel eine Möglichkeit vor, eine gemeinsame Basis für die Schätzung mit Story Points zu schaffen:
“Jedes Team sucht sich eine kleine Story aus, für die es einen Tag dauern würde, sie zu entwickeln, zu testen und zu validieren. Sie steht für die Größe “1”.”
(“Each team finds a small story that would take a day to develop, test, and validate. Call it a ‘one.’”)
Wir legen diese Referenzstory nur einmal fest, bevor wir mit der Schätzung beginnen. Außerdem ist diese Technik nur ein Vorschlag (SAFe: “ein Ansatz”). Wenn die Teams eine andere Heuristik bevorzugen, um die Größe der “1”-Story zu finden, können sie diese gerne verwenden. Die Teams können sich auf jede Methode einigen, um die “1” zu finden, solange sie eine Referenzstory ergibt.
Es kann nicht genug betont werden, dass dieser Algorithmus nur ein Leitfaden ist, um am Anfang die Story der Größe “1” zu finden. Die Referenz ist die gefundene Story, nicht ein Personentag.
Story Points haben eine Relation zum Aufwand, die sich mit der Zeit ändert.
Viele denken, dass bei “normalisierten Story Points” ein Story Point einem idealen Personentag entspricht. Das ist falsch. Das ist auch nicht das, was in SAFe steht.
Bei der relativen Schätzung mit Story Points wird der Aufwand von der Größe entkoppelt. Wir verwenden die prognostizierte Geschwindigkeit, um den Aufwand auf der Grundlage tatsächlicher, aktueller und sich entwickelnder Daten vorherzusagen. Ein festes Verhältnis zwischen Größe und Aufwand macht das gesamte Konzept und den Vorteil der Schätzung der Größe anstelle des Aufwands zunichte.
Warum wir Größe und Aufwand entkoppeln:
Zu jedem Zeitpunkt steht die Größe im Verhältnis zu Dauer und Aufwand. Der Faktor in dieser Beziehung ist die aktuelle Velocity (oder der Throughput). Die Velocity eines Teams ändert sich, wenn sich im Team etwas ändert (z. B. bessere Fähigkeiten, Einführung von Techniken wie Testautomatisierung). Wenn sich die Geschwindigkeit ändert, ändern sich auch die Dauer und der Aufwand. Während die Größe in der Regel stabil bleibt, ändert sich die Velocity tendenziell. Durch die Entkopplung von Größe und Aufwand können wir den Aufwand auf der Grundlage aktueller Daten vorhersagen, ohne dass wir die Elemente neu schätzen müssen. Die Entkopplung von Größe und Aufwand bedeutet, dass es keine feste Beziehung zwischen Größe und Aufwand gibt, sondern dass wir die aktuelle Geschwindigkeit nutzen, um eine aktuelle Vorhersage für den Aufwand zu treffen.
Das Angleichen (ungefähres Normalisieren) der Story Points ist optional.
Ich verwende oft den Begriff “angeglichen” statt “normalisiert”, wenn ich das Konzept erkläre, dass alle Teams das gleiche Verständnis von Größe haben. Ich tue das, weil viele Leute denken, dass “normalisierte Story Points” bedeuten, dass ein Story Point einem idealen Personentag entspricht. Von diesem Missverständnis und dieser schlechten Praxis möchte ich mich fernhalten.
Außerdem stelle ich in unseren Schulungen und SAFe-Implementierungen sicher, dass die Leute verstehen, dass “angeglichen (annähernd normalisiert)” nicht bedeutet, dass ein Story Point einen festen Aufwand hat. Angeglichen bedeutet nur, dass die Referenzstorys der Größe ‘eins’ (aus jedem Team) eine ähnliche Größe haben.
Ich stelle auch sicher, dass die Leute verstehen, dass diese Konzepte optional sind:
- Das Angleichen (ungefähres Normalisieren) der Story Points ist optional.
- Der Algorithmus zum Finden einer Referenzstory (“Jedes Team findet eine kleine Story, für deren Entwicklung, Prüfung und Validierung es einen Tag dauern würde. Nennen Sie sie eine “Eins”.) ist optional.
Eine alternative Technik zum Angleichen von Story Points
Du magst Alignment, aber du magst die in SAFe vorgeschlagene Technik nicht? Hier ist eine Alternative:
- Jedes Team wählt seine eigene Referenzstory für die Größe “Eins”.
- Vertreter/innen jedes Teams treffen sich und geben eine relative Einschätzung der Referenzstorys ab. Das führt dazu, dass einige Referenzstorys nach dem Abgleich eine “2” oder “3” (oder vielleicht etwas anderes) sind.
- Die Teamvertreter/innen gehen zurück in ihre Teams, wobei einige Referenzstories eine “2” oder “3” (oder vielleicht etwas anderes) nach der Angleichung sein können.
Dies ist jedoch eine fortgeschrittenere Technik, die von den Teams ein gewisses Verständnis der Story-Point-Schätzung erfordert.
Vor- und Nachteile der Angleichung (ungefähren Normalisierung) von Story Points
Wenn mehrere Teams gemeinsam an demselben ART Product Backlog arbeiten, kann es hilfreich sein, wenn sie eine einheitliche Definition der Größe “1” haben. Dies ermöglicht es den Teams, Größen teamübergreifend zu diskutieren. Zum Beispiel, wenn sie an einem gemeinsamen Feature arbeiten oder wenn sie eine Story von einem Team an ein anderes weitergeben.
Es kann auch sinnvoll sein, auf das Angleichen von Story Points zu verzichten. Ein Grund kann sein, dass fast alle Features von jeweils einem Team bearbeitet werden können und Storys nur selten geteilt werden müssen. In diesem Fall bringt ein Angleichen nicht viel Mehrwert. Ein anderer Grund für den Verzicht auf ein Angleichen kann sein, dass erfahrene Scrum Teams zusammenfinden, die schon eine existierende Story Point Skala haben.
Lies meine anderen Artikel über SAFe-Schätzungen.
Danke, liebe Rezensenten.
Schätzung ist ein schwieriges Thema. Ich möchte mich bei meinen Reviewern bedanken. Sie haben diesen Artikel erheblich verbessert. Es sind Simon Porro, David Croome, Philipp Erdmann, Hannes Jung und Matthias Faßbender. Außerdem haben wir diesen Artikel mit SAFe CoPilot verifiziert.
Willst du mehr erfahren? Dann besuche einen unserer Trainingskurse.
Wir behandeln die oben genannten Themen in unserem Leading SAFe Training oder in unserem Implementing SAFe Training. Erlebe ein Training mit vielen praktischen Aktivitäten, guten Diskussionen und erfahrenen Experten. Triff die Leute mit den meisten praktischen Erfahrungen in der Skalierung von Agilität und der Einführung von Business Agility.
Alle Zitate von der SAFe-Website sind © Scaled Agile, Inc.
