Meer grip op je Product Backlog in 5 stappen

Een goed georganiseerde Product Backlog is cruciaal voor het succes van elk Agile ontwikkelteam. Volgens de Scrum guide (versie 2020) is de Product Owner verantwoordelijk voor het beheren van de Product Backlog, maar kan zij het werk (of delen daarvan) delegeren aan anderen. En dat is precies wat er gebeurt: vaak worden de items op de Product Backlog gemaakt en uitgewerkt door meerdere mensen in verschillende rollen. Dat brengt uitdagingen met zich mee. Want hoe weten alle betrokkenen wat ze moeten doen? En hoe zorg je ervoor dat iedereen aan de juiste items van de backlog werkt?

Deze blog beschrijft vijf best practices voor succesvol backlog beheer. Het toepassen van de deze best practices zal helpen om meer grip te krijgen op het softwareontwikkelingsproces door een gestructureerde aanpak voor het beheren van de Product Backlog. De blog is gericht op iedereen die betrokken is bij de voorbereiding van Product Backlog Items, zoals de Product Owner, Business Analist en de ontwikkelaars die deelnemen aan de refinement van user stories. Het gaat ervan uit dat je bekend bent met de terminologie die wordt gebruikt binnen agile ontwikkeling en in het bijzonder Scrum. Deze blog gebruikt de term ‘user stories’ zoals geïntroduceerd door Mike Cohn in zijn boek ‘User Stories Applied‘ uit 2004.

1. Gebruik een statusflow voor de voorbereiding van user stories

Scrumteams gebruiken een statusflow voor het structureren van hun ontwikkelproces. De exacte statussen verschillen per team, maar meestal zijn er statussen om aan te geven dat een item via verschillende stappen, zoals ‘In Review’ en ‘In Test’, van ‘Klaar om op te pakken’ naar ‘Gereed’ gaat. Dit helpt het ontwikkelteam om het lopende werk bij te houden, het werk onder de teamleden te verdelen en het plan indien nodig aan te passen.

Ook het proces om een user story in de status ‘Klaar om op te pakken’ te krijgen, heeft baat bij een status flow. Het opstellen van een user story omvat verschillende stappen die onder regie vallen van de Product Owner. Door gebruik te maken van een statusflow voor het refinement-proces, worden alle betrokkenen op één lijn gebracht met de activiteiten die nodig zijn om ervoor te zorgen dat er voldoende werk is voorbereid voor de volgende sprintplanning.

De statussen die gebruikt worden voor het refinement-proces verschillen per organisatie, maar de opzet is altijd hetzelfde. Er zijn ten minste deze statussen nodig om de relevante stappen in het proces aan te geven:

• Nieuw: de user story is net gemaakt en is nog in voorbereiding. Er is nog weinig tijd in geïnvesteerd. Het bevat de meest relevante details zoals het doel van de user story, een korte schets van de beoogde functionaliteit en een eerste opzet van de acceptatiecriteria. Een user story in ‘Nieuw’ kan overeenkomen met tot 3 maanden werk en zal later vaak moeten worden opgesplitst in meerdere kleinere user stories.
• In refinement: de user story wordt voorbereid voor realisatie. In eerste instantie is het aantal mensen dat aan de user story werkt beperkt. Ze zullen indien nodig user stories opsplitsen, de details van de functionele wijzigingen en de voorgestelde technische oplossing voorbereiden.
• Wacht op inschatting: de scope, de oplossingsrichting en de acceptatiecriteria van de user story zijn voldoende duidelijk en de user story is klaar om besproken en geschat te worden met het ontwikkelteam.
• Klaar: de user story is volledig uitgewerkt en ingeschat en kan geïmplementeerd worden.

Uiteraard kan de naamgeving van deze statussen per organisatie verschillen. Sommigen noemen de ‘Klaar’ status ‘Klaar voor de Sprint’, terwijl anderen het ‘ Klaar om op te pakken’ noemen.

Veel bestaande backlog-tools, zoals Atlassian Jira of Microsoft Azure DevOps, maken het mogelijk om aangepaste statussen te definiëren. Hierdoor kunnen de Product Owner en het ontwikkelteam eenvoudig zien welke user stories uitgewerkt of ingeschat moeten worden.

2. Doorlopende schatting

Voor een Product Owner (en vele andere stakeholders binnen een organisatie) kan het nodig zijn om altijd een idee te hebben van de hoeveelheid werk die nodig is om een specifieke set user stories op de backlog af te ronden. Hier kunnen verschillende redenen voor zijn, afhankelijk van het type organisatie en product. Enkele voorbeelden:

• Een bedrijf heeft een product met een releasecyclus van 3 maanden en moet aan het begin van de iedere cyclus beslissen welke functies beschikbaar zijn voor release. Dit vraagt om een inschatting van alle user stories die het ontwikkelteam de komende 3 maanden moet oppikken.
• Een Product Owner moet een businesscase hebben voor de ontwikkeling van een bepaalde functie om te beslissen of de voordelen van de ontwikkeling opwegen tegen de kosten. Dit vraagt om een uitsplitsing van de benodigde werkzaamheden en in een agile omgeving is het logisch om deze uitsplitsing meteen in user stories te doen.
• Een team werkt aan een bepaalde feature, bestaande uit meerdere sprints aan user stories. Stakeholders binnen de organisatie moeten weten wanneer de functie klaar is. Dit betekent dat de Product Owner een schattingen moet hebben van de hoeveelheid werk die wordt vertegenwoordigd door alle user stories voor het feature voor de resterende sprints.

Natuurlijk willen we dat schattingen van user stories zo nauwkeurig mogelijk zijn. Dat betekent echter niet dat alleen volledig uitgewerkte user stories kunnen worden geschat. Over het algemeen geldt: hoe meer tijd er wordt geïnvesteerd in de voorbereiding van een user story, hoe nauwkeuriger de inschatting zal zijn (hoewel niet altijd, bijvoorbeeld als er informatie nodig is die niet beschikbaar is). Maar we hebben niet altijd de meest nauwkeurige schatting nodig van een user story.

Als je een sprintplanning doet, wil je de meest betrouwbare schatting hebben van alle user stories in de sprint, omdat je een sprint wil plannen die het team daadwerkelijk kan voltooien. Maar bij het geven van een prognose voor de totale inspanning die nodig is om 3 maanden werk te voltooien, heeft het geen zin om de details van elke user story volledig uit te werken. In dit geval volstaat een ruwe uitsplitsing in een paar meer algemene user stories, elk met een schatting op basis van aannames.

Vuistregel

Als vuistregel geldt dat je een schatting wil van elke user story in je backlog die mogelijk in de komende 3 maanden geïmplementeerd moet worden. Dus zelfs user stories in de statussen ‘Nieuw’ en ‘In refinement’ hebben een schatting nodig. En naarmate de user story gedetailleerder wordt uitgewerkt (en misschien opgesplitst in meerdere user stories), zullen de inschattingen waarschijnlijk veranderen op basis van nieuwe inzichten van de mensen die eraan werken. De inschatting kan dus meerdere keren veranderen, totdat de refinement is voltooid en de user story door het hele ontwikkelteam wordt geschat en in de status ‘Klaar’ wordt gezet.  Eenmaal in ‘Klaar’ zou de inschatting niet meer moeten veranderen en moet de user story zo snel mogelijk worden gerealiseerd. Als er te veel tijd zit tussen het einde van de refinement en de start van de realisatie door het ontwikkelteam, kan het nodig zijn om een user story te refinen en opnieuw te schatten om nieuwe inzichten mee te kunnen nemen.

Meestal bevat de bovenkant van de Product Backlog user stories in verschillende statussen. Omdat je de som van alle schattingen voor een set user stories wil kunnen bepalen, ongeacht hun status, kan je het beste hetzelfde veld en dezelfde eenheid gebruiken voor alle schattingen. Gebruik in Jira bijvoorbeeld het veld ‘Story Points’ voor zowel de vroege ruwe schattingen van nieuwe user stories als voor de stories die klaar zijn om te worden gerealiseerd. Dit maakt het mogelijk om alle ingebouwde rapporten en functionaliteit van Jira te gebruiken voor het beheersen van het agile ontwikkelingsproces.

3. Omarm het ritme

Bij agile ontwikkeling draait alles om ritme. Scrum schrijft een duidelijk gedefinieerde reeks evenementen voor, één keer per sprint (of zelfs dagelijks, in het geval van de dagelijkse stand-up). Elk van deze evenementen heeft een duidelijk doel en verloopt volgens een vaste structuur. Hierdoor weet iedereen die erbij aanwezig is hoe de dingen worden gedaan en wordt er weinig of geen energie besteed aan het uitzoeken van de beste werkwijze. Door de dingen elke keer op dezelfde manier en volgens een vast schema te doen, raken we ermee vertrouwd en weten we wat we van onszelf en van anderen kunnen verwachten. Hierdoor komt er tijd en energie vrij voor het werk dat voorhanden is.

Het uitwerken van een user story heeft net zo goed een ritme nodig. Je wilt een vaste reeks activiteiten doen voor elke user story, zodat er geen tijd verloren gaat aan het afstemmen met anderen over hoe de dingen moeten worden gedaan. En met een reeks terugkerende afspraken die één keer per week of sprint zijn gepland, weet iedereen dat er binnenkort gelegenheid is voor overleg en het stellen van vragen.

De refinement-bijeenkomst

De belangrijkste bijeenkomst van het refinement-proces is het overleg waarin het ontwikkelteam bij elkaar zit om de user stories te bespreken die nog worden uitgewerkt of al klaar zijn om te worden ingeschat. Dit overleg wordt bijgewoond door alle leden van het team en de perso(o)n(en) die de user stories hebben voorbereid (meestal een analist of de Product Owner). De bijeenkomst is bedoeld om ervoor te zorgen dat iedereen het doel van elk van de user stories begrijpt en de risico’s en uitdagingen rond de realisatie ervan kan beoordelen. Voor elke besproken user story zijn de meest voorkomende uitkomsten:

1. De refinement van de user story is voltooid. De user story wordt ingeschat door het team en de user story krijgt de status ‘Klaar’.
   of
2. De refinement kan niet worden voltooid omdat er enkele functionele of technische vragen zijn die eerst moeten worden uitgezocht. Iemand zal dit oppakken voor de volgende bijeenkomst, wanneer de user story opnieuw zal worden besproken.

Deze refinement-bijeenkomst valt niet onder de officiële evenementen zoals die gedefinieerd zijn in de Scrum Guide. Maar zoals elke bijeenkomst in Scrum is ook deze bijeenkomst een timebox. Wanneer de voor de bijeenkomst gereserveerde tijd voorbij is (meestal 1 uur per week), eindigt de bijeenkomst. Eventuele resterende user stories worden besproken tijdens de eerstvolgende geplande bijeenkomst. En soms is er een extra bijeenkomst nodig, bijvoorbeeld om ervoor te zorgen dat er genoeg user stories klaar zijn voor de volgende sprintplanning. Aan de andere kant, als er bovenin de Product Backlog voldoende uitgewerkte user stories staan om de volgende sprint (en nog wat meer) te plannen, kan de bijeenkomst korter zijn of volledig worden overgeslagen.

Hoe zit het met de kosten?

Deze refinement-bijeenkomst is een potentieel kostbare bijeenkomst. Afhankelijk van de grootte van het team kunnen er meer dan 10 mensen aanwezig zijn (inclusief analisten en de Product Owner). Het is dus belangrijk om de bijeenkomst effectief te houden. Iemand (meestal de scrum master of Product Owner) moet de bijeenkomst voorzitten en ervoor zorgen dat alleen user stories worden besproken die voldoende zijn voorbereid. Maak van de bijeenkomst ook geen ontwerpsessie. Als een discussie te lang duurt, wijs dan een aantal mensen aan om deze buiten de bijeenkomst af te maken en de refinement van de user story in de volgende bijeenkomst af te ronden.

4. Korte user stories

Grootte doet ertoe. Dat geldt voor bijna alles en zeker voor user stories. Wanneer de refinement van een user story klaar is, zou het idealiter niet meer werk moeten zijn dan één teamlid (theoretisch) binnen een week kan voltooien. Bij grotere user stories is de kans groot dat ze aan het einde van de sprint niet gereed zijn, simpelweg omdat ze moeilijker te overzien zijn. Dus wanneer het ontwikkelteam aan het einde van de refinement schat dat de grootte van een user story meer is dan een vooraf gedefinieerde bovengrens, wordt de user story opgesplitst in twee of meer user stories die opnieuw worden ingeschat. De bovengrens is afhankelijk van het team en kan hoger worden naarmate het team meer ervaring krijgt.

Feedbackloops

Er zijn verschillende redenen waarom het wenselijk is om user stories daadwerkelijk binnen één sprint kunnen realiseren. Allereerst draait het bij agile ontwikkeling om feedbackloops. Aan het einde van elke sprint heeft de Product Owner voltooide user stories nodig om feedback te kunnen krijgen over de bijgewerkte status van het product.  Maar agile development gaat ook over voorspelbaarheid. Een Product Owner heeft een ontwikkelteam nodig dat voorspelbaar is in de kwaliteit en hoeveelheid van het werk dat ze elke sprint leveren om de organisatie in staat te stellen deadlines en verplichtingen aan klanten en belanghebbenden na te komen. Afgezien daarvan verdient het ontwikkelteam zijn successen. Het voltooien van user stories motiveert het team en houdt het werk leuk.

Dat betekent niet dat elke user story op de backlog vanaf het begin klein moet zijn. User stories op de backlog die de status ‘Nieuw’ of ‘In refinement’ hebben, kunnen elke grootte hebben. Een hogere schatting van deze user stories is een vroege indicatie dat deze user stories waarschijnlijk complexer zijn en meer tijd nodig hebben om voor te bereiden. Naarmate het refinement-proces voor deze user stories vordert, moeten ze worden opgesplitst in kleinere user stories.

User stories opsplitsen

In principe kan een user story altijd opgesplitst worden in kleinere stories, hoewel dat een enkele keer een user story oplevert die minder concrete waarde levert voor de klant. Maar uiteindelijk levert het nemen van meerdere kleine stappen veel meer controle op dan het maken van één grote stap. Dus ook al kost het misschien wat extra inspanning (zoals het toevoegen van een featureswitch om nog niet voltooide functionaliteit in productie nog uit te kunnen zetten), er is nog steeds veel waarde in het hebben van user stories die vooral gericht zijn op het verminderen van risico’s of het treffen van technische voorbereidingen. Wanneer een user story te complex is om in één sprint te voltooien, is het zaak een aantal tussentijdse doelen stellen (en dus afzonderlijke user stories) en daar naartoe werken. Je verliest niets (de beoogde functionaliteit is nog steeds niet binnen één sprint afgerond) maar je krijgt wel controle en een kans om risico’s te verminderen.

5. Refinement is teamwork

Net zoals het realiseren van een user story een gezamenlijke inspanning van een heel team vereist, is het voorbereiden van user stories ook een teamprestatie. Er zijn specialisten uit verschillende disciplines nodig om de relevante details over functionaliteit, gebruikerservaring, technologie en kwaliteitsborging toe te voegen aan alle user stories in de Product Backlog. Binnen Scrum is de Product Owner verantwoordelijk voor het aanmaken en afstemmen van de items op de Product Backlog. In de praktijk hebben de mensen die belast zijn met het schrijven van de user stories functies als Business Analist, User Experience Designer, Architect of zelfs Product Manager.

In sommige organisaties zijn ze georganiseerd in aparte teams (vaak Product Teams genoemd), terwijl in andere organisaties deze mensen deel uitmaken van het ontwikkelteam dat de realisatie doet. In alle gevallen is het ontwikkelteam nauw betrokken bij het refinement-proces, aangezien zij ook bijdragen aan de inhoud van de user story en uiteindelijk een schatting afgeven.

Om al deze mensen dezelfde kant op te laten bewegen, is coördinatie nodig en dat is waar de Product Owner om de hoek komt kijken. Het belangrijkste instrument van de Product Owner voor het beheersen van het refinement-proces is de Product Backlog. Door de volgorde van de user stories op deze lijst te veranderen, bepaalt de Product Owner de volgorde waarin ze uitgewerkt moeten worden. Hier helpen de ruwe schattingen in de globale user stories haar om de prioriteiten te stellen en te bepalen welke user stories nu uitgewerkt moeten worden, en welke kunnen wachten tot later.

Kosten optimalisatie

Refinement in een just-in-time proces. Om tijd en geld te besparen, is het de bedoeling om alleen de details uit te werken die nu nodig zijn. Dus als een user story niet snel wordt geïmplementeerd of misschien helemaal niet wordt geïmplementeerd, wil je zo min mogelijk investeren in het uitwerken ervan. Voeg alleen de details toe die je nodig hebt om te beslissen of je de user story wilt behouden of niet. Als Product Owner wil je zonder enige terughoudendheid kunnen beslissen om een user story niet te realiseren, en daarin niet beïnvloed worden door de tijd die in de voorbereiding ervan is gaan zitten.

Uiteindelijk is het het tempo van het ontwikkelteam dat de snelheid bepaalt waarmee het refinement-proces plaatsvindt. Want het heeft alleen zin om het aantal user stories klaar te hebben voor realisatie dat het ontwikkelteam realistisch gezien in de volgende sprint (of twee) kan oppakken.

En nu…

Zet nu de volgende stap. Voeg statussen toe aan je Product Backlog, plan een wekelijks refinement-overleg, vul ruwe schattingen in voor niet-volledig-uitgewerkte user stories en kom in het ritme. Je zult zien dat het je helpt om beter georganiseerde sprints te krijgen, minder energie te verspillen aan discussies en vooral meer plezier te hebben.