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

Der WSJF Kalkulator im Excel Template, sowie eine Schritt für Schritt Anleitung stehen hier für dich zum kostenlosen Download bereit.

Download

Warum ist WSJF 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.

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.

Eine dieser kleinen Helfer bei der Erzeugung von Flow ist die WSJF Priorisierungsmethode, die ich heute diesen Artikel widme. WSJF Priorisierung ist eine Methode, die in SAFe zur Bewertung und Priorisierung eingeführt bzw. vorgeschlagen wird.

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.

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.

Sie 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.

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.

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 Feature‘s. 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.

Hier erhältst du das WSJF Excel Template

Der WSJF Kalkulator im Excel Template, sowie eine Schritt für Schritt Anleitung stehen hier für dich zum kostenlosen Download bereit.

Download

WSJF Priorisierung Schritt-für-Schritt