Rob den Hollander

Agile ontwikkelteams werken vanuit een eenduidig geprioriteerde backlog die bepaalt welke items achtereenvolgens opgeleverd moeten worden. In de dagelijkse praktijk wordt deze prioriteit vaak bepaald door de product owner.

Hierbij is het niet altijd voor alle partijen duidelijk hoe de product owner tot het uiteindelijke resultaat gekomen is. De prioritering van een backlog inclusief de achterliggende logica blijkt in de praktijk vaak een hele uitdaging!

In dit artikel kijken we naar de oplossing die SAFe biedt voor het eenduidig priorteren van een backlog: het WSJF principe.

Hoe prioriteer je een backlog?

Onder prioriteit/prioriteren verstaan we “het aanbrengen van een eenduidige ordening, zodanig dat inzichtelijk is geworden welk item eerst gerealiseerd moet worden, en welke daarna”.

De theorie vertelt ons natuurlijk dat de product owner de prioriteit bepaalt. Daarnaast zijn er verschillende methoden om tot een geprioriteerde backlog te komen. In de praktijk komt het er echter vaak op neer dat emotie (o.a. politieke druk of onderbuikgevoel) bepalend zijn.

In het algemeen wordt slechts beperkt rekening gehouden met de invloed van tijd, risico en opportunity. Laat dit nu net de factoren zijn die de prioriteit van items continu kunnen beïnvloeden. Hoog tijd dus voor een gestructureerde methode voor prioritering die deze factoren wel in overweging neemt.

Cost of Delay: de omgekeerde redenering

Binnen WSJF speelt het concept Cost of Delay een belangrijke rol. Om WSJF goed te kunnen begrijpen is het belangrijk om eerst stil te staan bij dit concept.

Bij prioritering op basis van Cost of Delay prioriteert u de items op de backlog niet op basis van de business value die ze kunnen genereren maar op basis van de ‘kosten’ die gemaakt zullen worden wanneer een item niet uitgevoerd wordt. De omgekeerde redenering dus.

In de volgende paragrafen bekijken we eerst een conceptuele toepassing van Cost of Delay om vervolgens te kijken hoe de Cost of Delay bepaald kan worden.

Cost of Delay: een voorbeeld

Stel… Uw backlog bestaat uit de volgende drie items: Item A, Item B en Item C. Voor het gemak stellen we de Cost of Delay voor deze items vast op 1, 2 en 10 en de ontwikkeltijd op 10, 3 en 1. Deze waarden zijn uiteraard relatief.

Als u ervan uit gaat dat de workflow zo ingericht is dat er altijd slechts aan één item tegelijkertijd gewerkt wordt dan kun u de totale Cost of Delay uitrekenen voor verschillende scenario’s waarbij de items A, B en C in verschillende volgordes geïmplementeerd worden.

Figuur 1 toont twee specifieke implementatiescenario’s met een verschillende totale Cost of Delay (het oranje gekleurde oppervlak). In het eerste scenario realiseren we de items in de volgorde A, B, C. In de tijd dat item A gerealiseerd wordt (10 tijdseenheden t) wordt niet gewerkt aan de andere items. Daardoor lopen item B en item C een Cost of Delay op van respectievelijk 20 (2 x 10t) en 100 (10 x 10t). Wanneer item A afgerond is wordt item B opgepakt. In de tijd dat item B gerealiseerd wordt (3 tijdseenheden) loopt item C nog eens een Cost of Delay op van 30 (10 x 3t). De totale Cost of Delay voor dit scenario (eerst A, dan B en dan C) is dus 20 + 100 + 30 = 150.

Het tweede scenario toont dat de omgekeerde volgorde (C, B, A) een totale Cost of Delay van slechts 6 heeft. Als we de totale Cost of Delay van beide scenario’s bekijken dan heeft het tweede scenario dus de voorkeur.

Figuur 1: Inschatting Cost of Delay per scenario voor de 3 items (A, B, C).

Voor dergelijke eenvoudige scenario’s kunnen we op gevoel en/of met een eenvoudig diagram de juiste prioritering te maken. Maar deze berekening zal een stuk moeilijker zijn wanneer de backlog groeit en de getallen voor de Cost of Delay en die voor de doorlooptijd dichter bij elkaar liggen.

In meer complexe situaties hebben we een andere methode nodig om onze prioriteiten te stellen. En liefst meteen een methode die naast de Cost of Delay ook de tijdsafhankelijkheid, het wegnemen van risico’s en het enablen van nieuwe opportunities in overweging neemt. De WSJF methode biedt ons precies wat we nodig hebben.

De Weighted Shortest Job First (WSJF) methode

De WSJF of “Weighted Shortest Job First” methode is gebaseerd op de volgende formule:

Hierbij bepaalt de som van de volgende drie parameters de Cost of Delay van een item:

• Business Value: geeft het belang voor stakeholders weer, maar ook mogelijk negatieve impact die opgelopen wordt wanneer het item vertraagt;
• Time Criticallity: geeft aan hoe de business value afneemt met het verstrijken van de tijd en houdt rekening met mijlpalen die behaald moeten worden;
• Risk Reduction & Opportunity Enablement: onderkent in welke mate dit item risico wegneemt in deze of een toekomstige oplevering, of relevante informatie (bijvoorbeeld nodig voor het maken van keuzes in de nabije toekomst) verkregen kan worden door implementatie van dit item.

De Duration staat voor een schatting van de “tijd” die nodig is om het feature te realiseren (bijvoorbeeld in story points).

Door de WSJF methode toe te passen op de backlog ontstaat een gepriorteerde backlog op basis van de “meeste waarde per tijdseenheid”. Het item met de hoogste WSJF krijgt hierbij de hoogste prioriteit.

Maar hoe bepaalt u nu de Business Value, Time Criticality, Risk Reduction en Opportunity Enablement? Het antwoord is eenvoudig: relatief ten opzichte van elkaar. Hierbij is de bepaling van deze parameters vergelijkbaar met de bepaling van story points zoals in verschillende agile estimation technieken!

WSJF: praktische toepassing

In de praktijk kunnen we deze parameters als volgt inschatten:

Stel een matrix op met op elke rij een (te prioriteren) item en in elke kolom een van de parameters van de WSJF-formule. Neem in elke kolom ten minste één keer de waarde 1 op voor het item met de kleinste business value (BV), de kleinste beïnvloeding door tijd (TC) en de kleinste beïnvloeding van het risico (RR)/de toegevoegde mogelijkheden (OE).

Schat vervolgens alle andere items in ten opzichte van deze waarde 1. Nadat alle velden gevuld zijn kan per item de Cost of Delay (BV + TC + RR|OE) bepaald worden. Na inschatting van de doorlooptijd (Duration) per item (in story points) kunt u eenvoudig de WSJF voor elk item bepalen. Figuur 2 illustreert deze oefening.

Feature 2: Bepaling van de “Weighted Shortest Job First” waarde voor de Items A, B, C en D.

De oplettende lezer zal vermoedelijk al vastgesteld hebben dat het belangrijkste onderscheidende element de doorlooptijd is geworden. Hoe groter de doorlooptijd, hoe lager de WSJF en hiermee dus ook de prioriteit van een item.Feature 2: Bepaling van de “Weighted Shortest Job First” waarde voor de Items A, B, C en D.

De invloed van de doorlooptijd bevordert derhalve het opbreken van items naar zo klein mogelijke eenheden (een belangrijke richtlijn in agile werken) en het zorgt voor een zo optimaal mogelijke flow van items door een team/programma!

… and do it again!

Bovenstaande vingeroefening is vrij snel uit te voeren. Gelukkig maar, want één van de problemen waar we tegenaan lopen is dat alles continu in verandering is.

We weten nu welke items de hoogste prioriteit hebben maar morgen ziet de wereld er alweer anders uit. In SAFe doen we deze exercitie daarom voor elke program increment (een periode van ca. 5 sprints van twee weken) opnieuw!

Cruciaal hierbij is om bij iedere inschatting weer met een schone lei te beginnen! Immers, alles is relatief en aan verandering (tijd, risico, opportunity) onderhevig. ‘Oude’ items kunnen van de backlog gevallen zijn (gerealiseerd of vervallen) en nieuwe items kunnen toegevoegd zijn.

Tip: Het scoren van grotere hoeveelheden items kan makkelijk en snel via relative mass valuation techniek. Deze methode faciliteert interactie en snel bereiken van consensus!

WSJF voor de prioritering van user stories?

Binnen het gebruik van WSJF binnen SAFe ligt de focus primair op het prioriteren van features. Een logische vraag is uiteraard of u de WSJF-methode ook kunt toepassen voor de prioritering van een backlog met user stories. Uiteraard kan dat, maar er zijn dan wel twee aandachtspunten te benoemen:

• Ondanks dat een user story ook volgens INVEST opgesteld/uitgewerkt zou moeten worden zien we in de praktijk nogal eens dat stories van elkaar afhankelijk worden. Op dat moment gaat de effectiviteit van de methode hard omlaag omdat dit een factor is waar we eigenlijk geen rekening mee kunnen houden.
• Een tweede praktisch probleem is de grote hoeveelheid user stories op een backlog. Een backlog met 100 tot 250 user stories is geen uitzondering… Wilt u met zulke grote aantallen elke paar weken deze exercitie uitvoeren? Waarschijnlijk niet. Voor een project/team dat werkt met een backlog van deze omvang is het overigens aan te bevelen om de abstractie naar features te maken!

Dus ja, u kunt WSJF gebruiken om een backlog met user stories te prioriteren, maar het is aan te raden om – zeker in grotere projecten – op feature level te prioriteren.

Hoe denkt u hierover?

Hoe prioriteert u uw backlog? Gebruikt u soortgelijke methodes en/of kunt u zich in deze methodes vinden? Heeft uw vragen of opmerkingen over prioriteren met behulp van WSJF of SAFe?

Aarzel niet en deel uw vragen en opmerkingen via het reactieformulier onderaan deze pagina, via info@divetro.nl of via +31 (0) 88 000 54 00. Wij helpen u graag verder.

Meer lezen?

Wilt u meer tips over Agile en/of analyse? Lees hier onze overige publicaties en schrijf u vrijblijvend in voor onze nieuwsbrief. U ontvangt onze publicaties dan automatisch wanneer ze op onze website verschijnen.

Schrijf u in