Das Problem von Priorisierungen mit diskreten Reihenfolgen
In aller Regel müssen Aufgaben und Arbeiten priorisiert werden, bevor sie für die Bearbeitung eingeplant werden. Denn natürlich soll und will sich kein Team ewig mit Nebensächlichkeiten aufhalten, während die wichtigen Dinge liegenbleiben.
Manch ein weniger erfahrenes Team könnte zunächst intuitiv zu der Meinung gelangen, dass man um die Priorisierung eines Backlogs kein großes Aufhebens zu machen braucht: Es setzt sich zusammen und kommt zu dem Schluss, dass eine Aufgabe wichtiger ist als die andere, und diese ist wiederum wichtiger als die dritte.
Zur Priorisierung nutzt das Team also ein simples Buchstabensystem: A, B, C, D, ... Oder Zahlenwerte zwischen 1 und 10 oder 1 und 100. Oder einen ähnlichen linearen Ansatz mit einer diskreten Reihenfolge. Leider haben sie alle gemeinsam, dass sie in der Praxis scheitern und zu Chaos führen, sobald es etwas komplexer zugeht.
Unterschiedliche Teammitglieder messen ein und derselben Aufgabe unterschiedlichen Wert bei. Trifft man sich in der goldenen Mitte? Aber wo bleibt bei diesem Kompromiss die Objektivität? Mehrere Storys sind priorisiert, doch wie verfährt das Team mit den Unteraufgaben? Erhalten sie alle dieselben Prioritäten wie das übergeordnete Ticket? Wie soll ein gewachsener Backlog oder ein Jira-Projekt mit hunderten Vorgängen in eine sinnvolle, praxistaugliche Reihenfolge gebracht werden? Nach dem Priorisierungsmeeting ist das Team im Grunde so schlau wie zuvor.
Mehr Granularität durch WSJF
Für solche großen Szenarien gibt es bewährte Alternativmethoden, die der Komplexität besser gerecht werden. Eine davon ist der WSJF. In dieser Abkürzung steht für W für Weighted, also "gewichtet", S für Shortest, also "kürzest", J für Job, also "Aufgabe oder Projektschritt", und F für First, also "kommt zuerst".
Frei formuliert: Mach zuerst, was wenig Aufwand erfordert und trotzdem viel Geschäftswert generiert! Nun, danach strebt eigentlich jedes Team.
Der WSJF-Ansatz wurde von Don Reinertsen entwickelt. Der Vorläufer "Shortest Job First" stammt aus den siebziger Jahren, in denen Computer-Ressourcen unglaublich teuer waren, sodass Teams sehr genau abwägen mussten, welche Arbeiten zuerst erledigt werden sollten. Damals waren es eben die Aufgaben mit den kürzesten Durchlaufzeiten. Don Reinertsen hatte schließlich noch die Gewichtung für Software-Teams eingeführt.
Wie funktioniert die WSJF-Priorisierung in der Praxis? Letztlich ist es nicht besonders schwierig. Beim WJSF bewertet das Team jede Aufgabe im Hinblick auf vier Dimensionen und berechnet daraus einen Zahlenwert, den WSJF-Wert. Und dieser eröffnet die Möglichkeit, systematisch eine eindeutige Reihenfolge zu bilden – selbst bei hunderten oder tausenden Tickets im Projekt oder Backlog.
Vier Dimensionen, die in die Priorisierung einfließen
Die vier Dimensionen werden jeweils mit Fibonacci-Zahlen versehen. Die ersten drei Dimensionen bestimmen die Cost of Delay, also die "Kosten der Verzögerung oder des Wartens". Sie setzen sich zusammen aus:
- User und Business Value (Geschäftswert): Wie profitieren die Kunden bzw. Nutzer (User Value) sowie das Unternehmen (Business Value) von der Umsetzung?
- Time Critically (Zeitkritikalität): Gibt es Termine, die eingehalten werden müssen? Warten Kunden dringend auf das Feature? Wäre der User und Business Value derselbe, wenn die Umsetzung erst später erfolgt?
- Risk Reduction und/oder Opportunity Enablement (Risikominimierung und/oder Chancengenerierung): Würde durch die Umsetzung ein bestehendes Risiko verringert? Oder würden neue Chancen entstehen, etwa durch zusätzlich gewonnenes technisches Know-how?
Um die Ausprägung dieser Dimensionen zu beziffern, nutzt das Team wie erwähnt eine (zumeist modifizierte) Fibonacci-Skala, die in der Regel aus den Werten 1, 2, 3, 5, 8, 13, 20, 40 und 100 besteht. Fibonacci-Zahlen sind deshalb praktisch und sinnvoll, weil die Abstände nach hinten hinaus stetig größer werden. Das passt gut zum Problem der Komplexitätsschätzung: Aufgaben, die das Team relativ genau beschätzen kann, lassen sich mit den niedrigeren Werten gut ausdifferenzieren (1, 2, 3, 5, 8, 13). Die höheren Werte weisen wiederum große Abstände auf (20, 40, 100). Insofern animiert der Ansatz dazu, größere Arbeiten in kleinere Teile aufzubrechen, die sich wiederum besser einschätzen lassen.
Übrigens: Die Fibonacci-Zahlen besitzen keine Dimensionen. Sie stehen nicht für monetäre Kosten oder Arbeitsstunden, und das Team sollte nicht versuchen, ihnen solche Werte überzustülpen. Die Fibonacci-Zahlen bilden relative Verhältnisse ab, das ist ihre Aufgabe.
Zur Bezifferung der Cost of Delay rechnet das Team die drei vergebenen Schätzwerte am Ende zusammen.
Die vierte Dimension, die in den WSJF einfließt, ist schließlich die Job Duration, also der voraussichtliche Aufwand für die bzw. die Dauer der Umsetzung. Auch hier kommen Fibonacci-Zahlen zum Einsatz – und wiederum nicht, um konkrete Zeitaufwände zu beziffern, sondern um die Verhältnisse zueinander abzubilden.
Der WSJF ergibt sich nun aus der Division von Cost of Delay durch Job Duration.
Je höher der WSJF-Wert, desto höher ist die Aufgabe priorisiert. Im Beispiel unten hat also Task B eine höhere Priorität als die Aufgaben A und C.
Es gilt:
If effort and CoD are different, do the WSJF first!
WSJF in Jira
Nun wäre es praktisch, mit der WSJF-Methode direkt in Jira arbeiten zu können, oder? Und zwar auf eine Art und Weise, die die Vergabe der WSJF-Werte durch die User zu einer einfachen Übung macht und die für eine größtmögliche Sichtbarkeit dieser Prioritäten sorgt. Die neue Jira-App Awesome Custom Fields erfüllt (unter anderem) genau diese Anforderung.
Sie versetzt Teams in die Lage, über benutzerdefinierte Felder, also Custom Fields, WSJF-Abfragen in ihre Vorgänge zu integrieren.
Die Werte für die WSJF-Dimensionen werden über einen komfortablen Dialog eingesammelt.
Der vergebene WSJF-Wert ist in allen Tickets als visuelles Element deutlich sichtbar hervorgehoben und auf entsprechend konfigurierten Boards immer transparent.
Im Vorgang ist der WSJF-Wert als visuelles Element sichtbar.
Sofern für ein Board die Anzeige des entsprechenden Custom Fields konfiguriert ist, wird der WSJF-Wert für alle Vorgänge auf den Karten angezeigt.
Die App holt Custom Fields in Jira ein Stück weit aus der technischen Ecke heraus und macht sie besser zugänglich, verständlicher und einfacher zu nutzen. WSJF ist längst nicht das einzige vorbereitete Custom Field, das die App mitliefert. Mit interaktiven Fortschrittsbalken, Multi-User-Auswahl, Sterne-Ranking, Statusampeln, Komplexitätsschätzungen in T-Shirt-Größen, Priorisierung nach der MoSCoW-Methode und anderen mehr bietet Awesome Custom Fields Felder für zahlreiche gängige Use Cases und Nutzungsszenarien in agilen Teams – und es werden stetig mehr.
Das folgende kurze Video gibt einen ersten Eindruck von den Möglichkeiten der App, und falls in deinen Teams ein erhöhter Bedarf an der Jira-Individualisierung mithilfe von Custom Fields besteht, lohnt sich definitiv ein zweiter, genauerer Blick.
Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Awesome Custom Fields für Jira: Jetzt kostenfrei installieren!
Awesome Custom Fields ist kostenfrei auf dem Atlassian Marketplace erhältlich – und steht erst am Anfang. Das Entwicklungsteam arbeitet intensiv daran, weitere Anwendungsfälle umzusetzen und noch mehr Konfigurationsoptionen bereitzustellen. Im weiteren Jahresverlauf wird das Team mehrere große Features ausliefern, die die Arbeit mit benutzerdefinierten Feldern nochmals erleichtern und gleichzeitig flexibler machen, beispielsweise die Erstellung von Custom Fields auf Projektebene.
Hast du Fragen? Möchtest du mehr zum Status quo und zur Zukunft der App wissen? Wünschst du dir bestimmte Use Cases, die in der App noch nicht vorhanden oder geplant sind? Dann melde dich: Das Team freut sich darauf, mit dir ins Gespräch zu kommen!
Weiterführende Infos
