Scrum
Story Points: Wieso, weshalb, warum und vor allem wie?
Was sind Story Points, warum gibt es sie überhaupt und wie kann man sie denn nun schätzen? All das erfahren Sie hier. Sie werden überrascht sein, was alles in ihnen steckt!
Weighted Shortest Job First (WSJF) ist eine Methode um schnell und effektiv Anforderungen zu Priorisieren. Wie wir gleich sehen werden, ist das Priorisieren von Anforderungen nicht nur wichtig, um den ROI zu maximieren, sondern die Methode ist ein wertvoller Baustein in lean-agile-Enterprise-Transformationen.
Welche Rolle die WSJF Priorisierung dabei spielt, vor allem aber wie sie funktioniert und praktisch eingesetzt werden kann, erfahren Sie hier in den folgenden Abschnitten.
Hier erhältst du das WSJF Excel Template inklusive den einfachen Step-by-Step Guide.
Der Übergang von Project to Product ist nicht nur ein Wechsel in der Arbeitsorganisation, sondern kennzeichnet einen fundamentaleren Wechsel der Perspektive von IT-Organisationen. Produkte werden als Ganzes wahrgenommen, bzw. wir beziehen uns auf Ihren vollständigen Life-Cycle. Früher waren wir eher noch geneigt, Produkte im Rahmen von kleinen Projekten weiterzuentwickeln.
Manchmal waren die Projekte auch gar nicht so klein, was dann weitere Fragen aufwarf. Agiles Projektmanagement erweitert mit der Einführung von neuen Techniken unseren Fokus auf die Produktentwicklung.
Der Begriff DevOps und der sich dahinter verbergende kulturelle Wandel von IT-Organisationen, würde beispielsweise ohne den Project-to-Product Perspektivwechsel wenig Sinn ergeben. Aber das nur zur Einführung, um den Rahmen zu setzen und der WSJF-Priorisierungsmethode die Bühne zu bereiten.
Im Gegensatz zu Projekten, werden Produktentwicklungen langfristiger gedacht, eben über den gesamten Lebenszyklus. Das wiederum hat einen Impact auf die Organisation, welche dieses Produkt plant, entwickelt, betreibt und weiterentwickelt.
Sie erzeugt, neben vielen anderen Dingen einen langfristigen und konstanten Flow an Features, begleitet durch Customer-Feedback, und unter Nutzung von vielen, wertvollen agilen Techniken, wie z.B. Design-Thinking, OKR oder anderen.
In Projekten wäre all das nur recht eingeschränkt möglich, denn es braucht schon viel Domain-Wissen und auch einiges an Zeit, sowie unzähligen Feedbackschleifen, um hier ein wirklich hohes Level zu erreichen, eben dieses Level, welches Flow erzeugt.
WSJF Priorisierung ist eine Methode, die in SAFe zur Bewertung und Priorisierung eingeführt bzw. vorgeschlagen wird.
Eine dieser kleinen Helfer bei der Erzeugung von Flow ist die WSJF Priorisierungsmethode, die ich heute diesen Artikel widme.
Ich bin mir gar nicht sicher, ob SAFe sie tatsächlich erfunden hat, darauf kommt es hier aber auch nicht an. Die WSJF Priorisierung ist in SAFe relativ leicht eingebunden, d.h. sie ist schon ein gewichtiger Helfer – um im Bild zu bleiben – aber sie lässt sich ohne weiteres auch in anderen Frameworks verwenden. Ähnlich wie z.B. Design Thinking Ansätze oder auch Scrum als Implementierungsmethode selbst.
WSJF steht also für “weighted shortest job first” und soll uns ein besseres Gefühl dafür geben, welche jobs wir zuerst machen sollen, also wie wir eine Reihe von Features, die auf ihre Implementierung warten, gut priorisieren.
Priorisieren ist in Projekten sicherlich leichter als in Produkten, daher steht auch diese Technik im Kontext des oben erwähnten Project-to-Product Perspektivwechsels.
Projekte haben in der Regel einen festen Rahmen und eine feste (geplante) Laufzeit, ich denke das ist naheliegend und wir müssen darauf nicht weiter eingehen. Auf die Aufgabe der Priorisierung hingegen müssen wir kurz eingehen, bevor ich die WSJF Technik und deren Einsatz erkläre, denn Priorisierung wird oft deutlich unterschätzt.
Priorisieren ist nämlich keine so leichte Angelegenheit, praktisch nicht und psychologisch auch nicht.
Denn Priorisieren bedeutet zuallererst sich zu entscheiden, etwas (jetzt) nicht zu tun. Damit aktiviert es zunächst einmal Verlustängste von Product Ownern und Stakeholdern.
Ich weiß, wovon ich spreche, denn als Product Owner und Stakeholder von Scagile habe ich sehr viel mehr Ideen, als egal welch großes Team überhaupt umsetzen könnte. Es ist oft frustrierend von den Entwicklungsteams ständig zu hören, “Das wird in diesem PI nichts, auf gar keinen Fall”. Und es hört ja nie auf, das Spiel wiederholt sich in jedem PI. Dabei wollen wir doch ein grandioses Produkt entwickeln und brauchen die Feature so dringend. Der Markt scheint sich so viel schneller zu entwickeln und saugt neue Feature so viel schneller auf, als wir entwickeln können.
So freundliche technische Errungenschaften wie Continuous Integration und Continuous Deployment bis hin zu Release on Demand machen das Ganze gefühlt noch schlimmer.
Priorisieren bedeutet deshalb auch, sich sehr viel Klarheit über den Gegenstand, also die zu priorisierenden Feature zu verschaffen – auch nicht immer einfach.
WSJF Priorisierung soll uns nun also helfen, unsere Frustration zu bekämpfen und aus uns vielleicht nicht vollständig glückliche-, doch aber zumindest zufriedene Product Owner und Stakeholder zu machen.
WSJF soll uns das Bewusstsein geben, dass wir zu jeder Zeit die richtigen Dinge tun, also effektiv bleiben.
Ich habe im Rahmen von SAFe die WSJF Priorisierung als ein sehr mächtiges und ebenso effektives Werkzeug kennengelernt und daher haben wir sie in Scagile vollständig als Tool integriert und sogar noch ein wenig erweitert.
Wie oben schon ausgeschrieben, steht WSJF für “weighted shortest job first” und das heißt so viel, dass die Feature eine höhere Priorität bekommen, die uns die schnellste Wertgenerierung in Aussicht stellen.
Ganz SAFe-like geht es also um Value und WSJF nimmt auf die Ökonomie der Feature direkt Bezug. Welche Feature schnelle Wertgenerierung in Aussicht stellen, ist nicht einfach die Frage, was bekomme ich schnell fertig, sondern fragt gezielt auch nach dem Wert der Feature.
WSJF Index = CoD*/Job Size
*CoD = Business Value + Time Criticality + Risk Reduction/OE
Die Frage kann auch umgekehrt werden und in der Umkehrung kommen wir der Erklärung der Methode gleich noch ein Schritt näher. Die Frage ist, was kostet mich ein Feature, wenn ich es zu spät oder gar nicht erhalte.
WSJF versucht also zunächst, die sogenannten “cost of delay” zu ermitteln. Diese Frage korrespondiert doch sehr gut zu unserem Priorisierungsproblem, sich also entscheiden zu müssen, etwas nicht zu tun.
Die Frage nach den “cost of delay” macht insofern Sinn, dass ein Feature nicht nur durch sein Business Value seinen Wert erfährt. DSGVO-Konformität z.B. hat sicher keinen besonderen Business Value, aber es kann doch sehr teuer werden, sie nicht rechtzeitig im Portal implementiert zu haben.
Demzufolge werden die “cost of delay” aus drei Werten bestimmt:
Letzterer versucht eine Einschätzung darüber zu geben, was das Feature in Zukunft sonst noch für uns tun kann. Es könnte z.B. uns langfristig einen Vorteil gegenüber Marktteilnehmern verschaffen, unsere USP besser herausarbeiten, oder künftig Risiken für Umstrukturierungen vermeiden helfen.
Um die drei Faktoren greifbarer zu machen, kann man sich jeweils folgende Fragen stellen:
Aus den drei Werten wird durch Addition die “cost of delay” errechnet.
Diese geteilt durch die job-size, also die Komplexität der Aufgabe, ergibt den WSJF-Index.
Die job-size repräsentiert die Komplexität der Aufgabe, denn diese hat einen Einfluss auf den Aufwand und die Dauer. Aufwand und Dauer sollten hier nicht direkt geschätzt werden, denn sie weisen eher auf Eigenschaften der Feature-Teams. Hier soll aber eine Eigenschaft des Feature ermittelt werden, daher Komplexität.
Denn oft ist bei der Bewertung von Anforderungen noch gar nicht klar, welches Team das Feature implementieren wird, bzw. die Velocity des Teams ist nicht bekannt, oder unterliegt stärkeren Schwankungen. Das Schätzen ist ohnehin keine präzise Wissenschaft, man sollte es sich also nicht noch schwerer machen, als es ohnehin schon ist.
Daher wird bei der Bewertung aller vier Dimensionen auch eine Vergleichsschätzung vorgenommen.
So, wie wir sie aus der Schätzung von Storys und Features mit Story Points schon kennen. Man kann dabei sicher jede beliebige Metrik verwenden, eine 10er Skala, T-shirt Sizes oder anderes.
Mein Vorschlag wäre allerdings auch hier StoryPoints mit der angepassten Fibonacci-Folge zu verwenden:
0,1,2,3,5,8,13,20,40,100
Agile Teams verwenden sie meist schon, sind also in ihrem Umgang geübt und insbesondere kann die job-size dann leichter mit der Velocity der Teams in Beziehung gebracht werden, um doch noch die Dauer besser zu bestimmen. Zumindest dann, wenn alle beteiligten Teams eine synchronisierte (normalisierte) Skala verwenden. Aber auch andere Schätztechniken, wie z.B. “magic estimation” können durchaus angewendet werden
Die Bewertung ist dann besonders effektiv, wenn man sie über die Feature spaltenweise vornimmt, also zunächst mal für alle Feature den Business Value ermittelt, dann die Spalte Time Criticality und dann die beiden anderen.
In der Folge wird jedes weitere Feature mit diesem Favoriten verglichen. In Scagile beispielsweise kann man diesen Favoriten markieren, damit man ihn in jedem folgendem PI wieder verwenden kann.
Beim Vergleich stelle ich mir meist die Frage, ist der Business Value des aktuellen Feature verglichen mit dem Favoriten, größer, viel größer, kleiner oder viel kleiner. Meist genügt das schon, denn wenn der Favorit eine mittlere Größe hat (z.B 8 oder 13) dann ist kleiner 5 oder 3, viel kleiner 1 oder 2, größer 20, viel größer 40 oder sogar 100.
Diese Bewertung geht recht schnell und fällt den Beteiligten in der Regel auch sehr leicht. In vielen Projekten konnten so ganze Backlogs mit einigen zig oder auch über 100 größeren Anforderungen mit einer Entwicklungszeit von weit über einem Jahr in weniger als 2 Stunden bewertet werden. Das ist in jedem Fall immer gut leistbar.
Ein weiterer und wesentlicher Vorteil dieser Technik besteht darin, dass viele Beteiligte der Business- und IT-Organisaiton an einen Tisch kommen und sich über die Anforderungen unterhalten. Die Priorisierung ist also keine einsame Entscheidung von wenigen Stakeholdern, sondern echte Teamarbeit und sie schafft Transparenz.
Business Value wird sicher meist von Fachabteilungen oder Marketing bewertet, Time-Criticality involviert oft Legal und Compliance, Risk-Reduction/Opportunity Enablement das strategische Management und job-size natürlich die Feature-Teams.
Das macht die WSJF-Priorisierung zu einem Werkzeug, welches nicht nur unsere Priorisierungs-Frustration lindert, sondern auch gleichzeitig unsere agile Kultur fördert.
Wenn man dabei noch ein cooles Tool nutzen kann, dann macht es sogar noch Spaß oder ist mindestens recht unterhaltsam und keineswegs eine zähe Veranstaltung.
Neben dem WSJF-Index sind für die finale Reihenfolge sicher auch noch andere Faktoren zu berücksichtigen, wie z.B. Abhängigkeiten unter den Features.
Insofern liefert die WSJF-Methode und der WSJF-Index einen qualifizierten Vorschlag.
Die Stärke der Methode liegt meiner Erfahrung nach besonders darin, dass er für einen Priorisierungsprozess klare, diskutierbare und bewertbare Kriterien liefert und somit den Prozess gut strukturiert und für die nötige Transparanz im Change- bzw. Demandmanagement sorgt.
Meine Empfehlung dabei ist, dass beim Beschreiben der Feature schon direkt auf die drei cost-of-delay-Faktoren Bezug genommen wird
Das macht das pitchen der Anforderungen dann deutlich einfacher und die Anforderer können sich frühzeitig über die “cost of delay” Gedanken machen. Auch erleichtert es oft das Schreiben der Anforderungstexte, denn man hat schon ein hilfreiches Template für die zu beschreibenen Anforderungen.
Wir haben auch die Erfahrung gemacht, dass Stakeholder sich beim Schreiben ihrer Anforderungen dann öfter schon mal mit ihren Feature-Teams austauschen, um ein Gefühl für die job-size zu bekommen. Das fördert ungemein eine lean-agile culture, oft weit mehr, als einige gemeinsame Teambuilding Events. Gleichzeitig ist die WSJF-Methode sehr einfach und sehr schnell und ohne großen Aufwand umsetzbar.
Hier erhältst du das WSJF Excel Template inklusive den einfachen Step-by-Step Guide.
Der WSJF Kalkulator ist direkt in die scagile Projektmanagement App integriert.
Unser Team aus erfahrenen und zertifizierten Agile Expert:innen entwickelt kontinuierlich praxiserprobte Strategien und Methoden, um agile Prozesse zu optimieren und mit den täglichen Herausforderungen besser umgehen zu können.
Was sind Story Points, warum gibt es sie überhaupt und wie kann man sie denn nun schätzen? All das erfahren Sie hier. Sie werden überrascht sein, was alles in ihnen steckt!
Wie schreibt man eine gute Scrum User Story? Hier erklären wir dir, worauf es ankommt …und worauf nicht.
Welche Status Sie in Ihrem Scrum Board tatsächlich brauchen und warum Sie NUR mit diesen erfolgreich sein werden, erfahren Sie hier.
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
