De prioritering van user stories is een essentieel onderdeel van product backlog management. De product owner is daarvoor verantwoordelijk.
Door de structuur van de product backlog wordt hij of zij gedwongen om keuzes te maken. De user stories moeten namelijk op volgorde van prioriteit komen te staan. Twee user stories op dezelfde plek in de product backlog is niet toegestaan.
Prioriteren / sorteren
Scrum spreekt bewust van ‘sorteren’ en niet van ‘prioriteren’. De reden is dat prioriteren gewoonlijk wordt geassocieerd met businesswaarde en met functionaliteiten die de stakeholders het liefste willen hebben.
Bij het sorteren en hersorteren van user stories moet de product owner echter meer aspecten dan alleen de businesswaarde in ogenschouw nemen en zich uitgebreid laten adviseren door het agile team en de stakeholders. Daarbij spelen zowel business, procesmatige als technische aspecten een rol.
Houd rekening met de volgende aspecten
De 6 voornaamste aspecten voor het prioriteren/sorteren van user stories op de product backlog zijn:
1. Businesswaarde
De features die de meeste waarde creëren voor de gebruikers en de organisatie, wil je in principe als eerste implementeren. Dat zijn de features die noodzakelijk zijn om het productdoel en de achterliggende strategie van de organisatie te realiseren. Daarbij zijn ook de Return on Investment (rendement op de investering), terugverdientijd en de Total Cost of Ownership (o.a. onderhoud-, beheer en licentiekosten) van belang.
2. Onzekerheid over de functionele oplossing
Soms wil je bepaalde user stories voorrang geven om te toetsen of je de juiste oplossingsrichting gekozen hebt. Bijvoorbeeld of de oplossing inderdaad tot de voorspelde kostenbesparing leidt, of dat er voldoende vraag is naar het product.
3. Onzekerheid over de technische oplossing
Om technische risico’s uit te sluiten kan het noodzakelijk zijn bepaalde user stories op korte termijn te realiseren. Dat geeft het agile team de mogelijkheid de technologie beter te doorgronden.
4. Afhankelijkheden met andere teams of externe leveranciers
Soms kunnen bepaalde user stories pas gerealiseerd worden nadat andere teams hun werk gedaan hebben, of moet je zelf een story in de sprint opnemen ten behoeve van een ander team.
5. Afhankelijkheden tussen user stories
Soms is het beter of zelfs noodzakelijk om eerst de ene en pas daarna de andere user story te implementeren. Dit kan om technische redenen of om bedrijfsmatige redenen zijn. Het heeft bijvoorbeeld pas zin om functionaliteit voor iDEAL betalingen toe te voegen wanneer het überhaupt mogelijk is om een bestelling te plaatsen.
6. Timing
Sommige features hebben veel meer waarde als je de concurrentie voor bent, of hebben bijvoorbeeld alleen waarde rond de feestdagen (window of opportunity). Ook de gederfde inkomsten of kosten van het nu nog niet implementeren van een user story zijn van belang (cost of delay).
Conclusie
Uitsluitend prioriteren op businesswaarde is te beperkt. Je moet ook rekening houden met procesmatige en technische aspecten. De voornaamste aspecten hebben we voor je in een infographic gezet. Klik hier of op de afbeelding op de infographic te openen.
Met welke van deze aspecten houd jij im-of expliciet al rekening bij het prioriteren? Kun je een voorbeeld geven? Dat helpt andere lezers op weg. Plaats je voorbeeld of opmerking in het reactieveld hieronder.
Nicole de Swart & Priya Soekhai
