Wat is een product backlog?

De backlog is een lijst met de benodigde ontwikkelingen en aanpassingen die uitgevoerd moeten worden om het product te optimaliseren. De product owner is verantwoordelijk voor de inhoud, de beschikbaarheid, en het ordenen van deze lijst. Betekend dit dat de product owner de enige is die aanpassingen mag maken aan de backlog? Goeie vraag! Het antwoord is “nee”. De product owner is verantwoordelijk voor de backlog, maar dat sluit niet uit dat hij de taken niet mag delegeren. Sterker nog, de backlog wordt uiteindelijk uitgevoerd door het development team en bevat beschrijvingen van alle stakeholders. Dit kan de interne budgethouder zijn, maar ook directe feedback van de gebruiker. Het is daarom essentieel om het Scrum team hierbij te betrekken en om samen user stories te schrijven, te refinen en te ordenen. Uiteindelijk is het hele team verantwoordelijk voor het resultaat aan het einde van de sprint. Daarnaast draagt dit ook meteen bij om je stakeholder management op peil te houden.

De backlog is een lijst met alle features, vereisten, functies, verbeteringen en oplossingen die in de toekomstige releases in het product moeten worden aangebracht. Een backlog item heeft de kenmerk van een beschrijving, volgorde, schatting en waarde. Het bevat vaak een tekst beschrijvingen die aanduidt wanneer een item done is. Een feature wordt opgedeeld zodat het klein genoeg is om in een sprint op te pakken. Zo’n item wordt ook wel een user story genoemd. Tijdens een refinement sessie wordt de user story aangevuld met een goede beschrijving, acceptatie criteria en waarde voor de eindgebruiker. Deze uitgewerkte user stories worden gebruikt om de product backlog items te prioriteren. Wanneer de story klaar is kan deze opgenomen worden in de sprint backlog. Hoeveel user stories je per sprint kan verwerken ligt aan de complexiteit en volwassenheid van je team. Naar mate het team groeit neemt de velocity toe. Meer over het inschatten van werk lees je in onze blog ‘hoe schat je werk in als product owner?‘.

Wanneer er voldoende items gedefinieerd zijn en ze in één sprint door het development team als “done” kunnen worden uitgevoerd, dan worden de items als “ready” beschouwd voor selectie in een sprint planning en worden deze toegevoegd aan de sprint backlog. Het wordt aangeraden om voor 2 á 3 sprints aan items in je product backlog te hebben staan. Wanneer er onder een item of functie meerdere user stories vallen dan is het aangeraden om hiervoor een epic aan te maken.

De product backlog is niet zomaar een lijst. Vaak komen nieuwe features of verbeteringen voort uit een roadmap. Afhankelijk van het product is dit een visie waar het product naartoe zou moeten ontwikkelen in de komende 3 tot 6 maanden. Meer hierover lees je in onze blog over productvisie of in het product owner boek.

Bij het opstellen van een Product Backlog wordt vaak DEEP en INVEST gebruikt. Gebruik DEEP (detailed, emergent, estimated, prioritized) als leidraad voor het beheren van de product backlog en INVEST (independent, negotiable, valuable, estimable, small, testable) als checklist om user stories van hoge kwaliteit te garanderen.

Het stellen van prioriteiten binnen de product backlog is een van de cruciale taken van een product owner. Het is een continu proces van afwegen en beslissen wat op een bepaald moment het belangrijkste is om te realiseren. Dit houdt niet alleen in dat men kijkt naar wat de hoogste waarde oplevert voor de klant of eindgebruiker, maar ook wat technisch haalbaar is binnen de gegeven omstandigheden.

Als product owner prioriteer je op basis van onder andere:

Als product owner word je dagelijks geconfronteerd met een stortvloed aan op het oog goede ideeën, ‘urgente’ verzoeken en diverse verwachtingen. Hoe bepaal je wat de grootste impact heeft? Hoe zorg je ervoor dat je tijd en middelen het beste inzet? Hoe houd je je stakeholders tevreden zonder de koers van je product te verliezen?

Het is niet verplicht in Scrum om de backlog te prioriteren. Het kan zijn dat één item een hoge waarde en prioriteit heeft voor de ontwikkeling van het product. Om dit item te ontwikkelen moeten er misschien eerst 2 andere items ontwikkeld worden voordat dat het ene item gebouwd kan worden of functionaliteit krijgt. Als je zou gaan prioriteren komt het eerste item bovenaan de product backlog te staan en zal deze in de eerste opkomende sprint uitgevoerd worden. Echter, werkt deze daarna nog niet omdat de andere 2 items niet in de sprint zaten vanwege hun lagere prioriteit. En zal het opgeleverde item nóg geen waarde toevoegen aan het product.

Voorbeeld; Stel je een zeilboot voor. In eerste instantie denk je dat de zeilen erg essentieel zijn voor een zeilboot. Zonder de zeilen komt de boot niet vooruit. Dus deze zeilen zullen een erg hoge prioriteit hebben. Alleen zonder een mast kan het zeil niet gehesen worden. Wat ga je dan als eerst willen bouwen?

Het doel van een product backlog is door middel van de productvisie, gebruiker en stakeholder behoefte, en de kennis van het Scrum team te bepalen en beheren welke product backlog items hoge prioriteit hebben om in elke sprint de meeste waarde toe te voegen aan het product.

Door de product backlog continue te delen en te bespreken met het Scrum team en de stakeholders, ontstaat er transparantie over de huidige status van het product. Dit helpt de product owner bij het bepalen wanneer items “done” zijn en welke items als eerste ontwikkelt moeten worden om op een efficiënte manier de waarde van het product te verhogen en de gebruiker tevreden te stellen.

Wil jij hier direct mee aan de slag gaan? Download onze gratis templates of volg de product owner in de praktijk training. Wil je dieper duiken in de visie achter het product? Volg dan de training productvisie voor product owners.