Er zijn altijd meer eisen en wensen dan dat er tijd en budget is om ze te realiseren. Of is dat in jouw organisatie anders?
Het gevolg is dat er keuzes gemaakt moeten worden, ofwel je moet prioriteren stellen. De meeste mensen hebben daar moeite mee. Ze doen het liever niet. Dat geldt ook voor veel product owners en stakeholders.
Toch ontkom je in agile niet aan het prioriteren van de product backlog. In dit artikel geven we 4 tips om dat gemakkelijker te maken. En we hebben er ook een infographic van gemaakt.
Prioriteren op businesswaarde
Het meest gebruikte criterium voor het prioriteren van user stories is businesswaarde. Dat is op zich een prima criterium maar meestal te vaag.
Als je de user stories op de product backlog wilt prioriteren naar businesswaarde, beland je al snel in discussies met subjectieve argumenten.
Hoe bepaal je bijvoorbeeld welke user story de meeste businesswaarde creëert, als je de wensen van verschillende stakeholders tegen elkaar moet afwegen?
Maak in 4 maanden de sprong van beginnend naar volwaardig agile analist
Prioriteit geven
Gebruik onderstaande tips om te bepalen welke user stories prioriteit krijgen.
TIP 1 – Richt je op het productdoel
Beoordeel de user stories niet ten opzichte van elkaar maar relateer de businesswaarde van een user story altijd aan het productdoel.
Het productdoel geeft de toekomstige staat van het product weer en maakt duidelijk waarom de business de software wil laten ontwikkelen. Wat hoopt de business ermee te bereiken, wat gaat het ze opleveren?
Hebben ze de nieuwe software bijvoorbeeld nodig om de klanttevredenheid te vergroten, aan wet- en regelgeving te voldoen of om de productiviteit te verhogen?
Het productdoel is de doelstelling van het agile team, waar ze sprint voor sprint naartoe werken. Zoek de epics en user stories die het meest bijdragen aan het productdoel.
TIP 2 – Verkort jullie horizon
Vaak is het verstandig om voor het behalen van het productdoel, tussendoelen of mijlpalen te definiëren.
Het team bepaalt wat de eerstvolgende grote stap richting het productdoel gaat zijn. Dat kan bijvoorbeeld een minimum marketable feature (MMF), minimum viable product (MVP) of een (beta)release zijn.
Die mijlpaal mag niet te ver in de toekomst liggen, want dan blijft de businesswaarde en welke user stories daarvoor gerealiseerd moeten worden te vaag. Een horizon van enkele sprints tot maximaal 3 maanden is ideaal.
Neem alleen de user stories die noodzakelijk zijn voor het behalen van de eerstvolgende mijlpaal in ogenschouw bij de prioritering.
TIP 3 – Kijk verder dan alleen businesswaarde
Businesswaarde mag dan wel het voornaamste criterium zijn bij het prioriteren van de product backlog, maar zeker niet de enige. Je moet veel meer aspecten in ogenschouw nemen. Zowel business, procesmatige als technische aspecten zijn van belang.
Welke aspecten precies? Dat lees je in het artikel De 6 voornaamste criteria voor het prioriteren van de product backlog.
TIP 4 – Houd elke sprint de prioritering tegen het licht
Het scrum team bekijkt elke sprint of er aanleiding is om de user stories en de prioritering daarvan bij te stellen. Dat doen ze tijdens of kort na de sprintreview op basis van de feedback van de stakeholders in de sprintreview.
Het team vraagt zich dan af wat er nu als eerste moet gebeuren om de mijlpaal (MVP, beta release) op tijd te realiseren.
Moet de recent gerealiseerde functionaliteit verder verbeterd of uitgebreid worden? Of is het belangrijker om eerste de kern van een andere epic te bouwen?
Als er in de prioritering op de product backlog meerdere sprints achter elkaar niets wijzigt, is dat een signaal dat er onvoldoende gebruik wordt gemaakt van voortschrijdend inzicht. Maar dat is een ander topic. Meer daarover lees je in het artikel Gebruikers weten niet wat ze willen.
Infographic
Dit waren onze tips voor het prioriteren van de user stories op de product backlog. We hopen dat hiermee het prioriteren gemakkelijker wordt en de product backlog overzichtelijker.
Als bonus hebben we er een infographic van gemaakt, zodat je de tips eenvoudig met collega’s kunt delen. Klik hier of op de afbeelding om de infographic te openen.
Nicole de Swart & Priya Soekhai
Nicole,
Ofwel lees ik het verkeerd ofwel zit er een tegenstrijdigheid:
in tip 1 staat in de beschrijving ” Beoordeel de user stories niet ten opzichte van elkaar maar….” en in het kader staat: “Zoek de epics en user stories die het meest bijdragen aan het productdoel..” Hoe weet je welke user stories het meest bijdragen als je ze niet onderling vergelijkt? Is een “schatting” van de bijdrage niet sowieso subjectief en zeer onnauwkeurig?
Business doelen worden meestal slechts een zekere tijd (en dit kan zelfs een vrije lange tijd zijn) na het realiseren van het product (zelfs in een rudimentaire vorm) bereikt. Hoe kan je dan een nauwkeurige schatting maken op korte termijn? Hogere klantentevredenheid bereik je zelden na 3 maand of zo…
Hoe rijm je dat (tot nu toe heb ik geen enkele aanpak gezien die business waarde nauwkeurig en objectief kan bepalen en waarbij achteraf bleek dat die ook correct was)?
Rik, Met tip 1 bedoelen we dat je user stories altijd relateert aan het productdoel. Dus niet rechtstreeks met elkaar vergelijkt, maar als het ware via het productdoel (of zaai ik met deze uitleg nog meer verwarring?).
Over je punt van een nauwkeurige en objectieve schatting: Dat is inderdaad niet te doen. Het grote verschil tussen de traditionele en agile werkwijze is: alles vooraf analyseren/uitdenken/plannen versus proefondervindelijk gaandeweg ontdekken wat wenselijk/handig/het beste is. In agile probeer je niet de businesswaarde van elke user story nauwkeurig te schatten, maar je werkt iteratief en incrementeel en blijft continu leren en bijsturen (inspect & adapt). Je begint met de user stories waarvan de product owner denkt/inschat dat ze nu het belangrijkste zijn. Aan het eind van de sprint check je of de verwachtingen uitkomen en wat de volgende stap (user stories) richting het productdoel zal zijn.