Priorisierung mit der WSJF Methode [+ Excel Template]

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.

Priorisieren mit der WSJF Methode | scagile Blog

Inhalt dieses Artikels

Dein kostenloses WSJF Excel Template

Hier erhältst du das WSJF Excel Template inklusive den einfachen Step-by-Step Guide.

Warum ist die WSJF Methode im agilen Umfeld so wertvoll?

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.

Previous slide
Next slide
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.
Project
Product

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.

Agile Transformation: Ziele & Metrics

Agile Transformation Ziele & Metrics – Damit Ihre Agile Transformation nicht scheitert, sollten Sie unbedingt Ziele definieren – aber vor allem messen! Wie und welche, erfahren Sie hier.

Die WSJF Methode erklärt

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.

Jetzt können wir schnell und nahezu ad hoc releasen, bekommen aber alle Feature gar nicht so schnell entwickelt, wie wir sie gerne hätten.

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

Story Points: Wieso, weshalb, warum, aber 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!

Wie berechnet man den Cost of Delay nach SAFe?

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:

Business Value

Time Criticality

Risk Reduction /

Opportunity Enablement

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:

Business Value

Was ist der Wert des Feature für den Nutzer? Wie wichtig wird dieses Feature für den Nutzer sein? Welchen Impact könnte dieses Feature auf den Umsatz mit dem Produkt haben?

Time Criticality

Wie dringend ist das Feature für das Business des Nutzers? Gibt es gesetzliche, oder geschäftliche Deadlines für das Feature(z.B. Inkrafttreten eines Gesetzes, Weihnachtsgeschäft) Werden Nutzer warten oder sich lieber einem anderen Anbieter suchen?

Risk Reduction / Opportunity Enablement

Wie wichtig ist das Feature um künftige Risiken zu vermeiden? Könnte das Feature später neue Business Opportunities ermöglichen?

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.

Wie berechnet man 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.

Dabei sucht man sich z.B. für den Business Value einen Favoriten, also ein prägnantes Feature, idealerweise mittlerer Größe, welches man sehr gut einschätzen kann und gibt diesem einen Wert.

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.

Die App für scaled agile Teams ist da!

Weitere Vorteile der WSJF Methode

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.

Sie sollten es einfach mal ausprobieren.

Dein kostenloses WSJF Excel Template

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.

Bist du Scrum Master, Agile Coach
oder Product Owner?

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.

Diese Erkenntnisse möchten wir dir nicht vorenthalten!
Schau gerne hier vorbei:

Klicke, um Artikel mit den gleichen Tags zu zeigen:

Klaus Riedel
Als agile Coach begleitete Klaus Riedel mit seinem Team die digitale Transformation und die Einführung von Scrum und SAFe in großen Organisationen wie Deutsche Bank, Conrad Electronics, Volkswagen, PWC und anderen.

Alle seine gewonnenen praktischen Erfahrungen in mehr als 15 Jahren agile Transformation sind in die Artikel seines Blogs eingeflossen.

In der Scagile Academy bildet er Nachwuchs Agile Experts aus und seit 2016 unterrichtet er agiles Projektmanagement an der deutschen Fakultät der TU Sofia.

Mehr interessante Artikel für dich:

Dein kostenloses WSJF Excel Template + Step-by-Step Guide

Wir senden dir dein kostenloses WSJF Excel Template zur einfachen Backlog Priorisierung inklusive Schritt für Schritt Anleitung per Email zu. Gebe dazu bitte hier deine Kontaktdaten ein.

WSJF Excel Template | scagile

hbspt.forms.create({
region: „eu1“,
portalId: „27088745“,
formId: „c28f7eb5-39b9-475c-8903-f88c9886f62e“
});