De actuele Product Backlog van een Scrum team

Een gezonde Product Backlog lijkt veel op een gezond mens: verzorgd, geordend en toegankelijk. Een goed geprioriteerde, flexibele backlog maakt de release- en iteratieplanning eenvoudiger. Tevens bevat het workitems waar je team graag tijd aan wil besteden, ook intern werk dat de opdrachtgever nooit zal opmerken. Dit draagt bij aan het wekken van de juiste verwachtingen bij de belanghebbenden en andere teams, vooral als ze aanvullende workitems voor je moeten opleveren.

Wat is een Product Backlog?

Een Product Backlog is een geprioriteerde lijst van workitems voor het ontwikkelteam die is afgeleid van de roadmap en de requirements. De belangrijkste workitems staan bovenaan in de Product Backlog. Zo weet het team wat als eerste moet worden opgeleverd. Het ontwikkelteam werkt niet onder druk van de Product Owner aan bepaalde stukken en de Product Owner is niet aan het pushen. In plaats daarvan haalt het ontwikkelteam workitems uit de Product Backlog als er ruimte voor is, hetzij continu (Kanban) of door iteraties (scrum).

• Een product backlog is een geordende, dynamische lijst van alles wat nodig is om een product te verbeteren. 
• Het bevat functies, user stories, wijzigingen, verbeteringen en bugfixes die voor toekomstige releases nodig zijn. 
• De Product Owner is verantwoordelijk voor het beheren en doorontwikkelen van de product backlog. 

Begin met de Roadmap en de Requirements

De Roadmap en Requirements van een team vormen de basis voor de Product Backlog. De roadmap valt uiteen in verschillende epics en iedere epic heeft andere requirements en userstories.

De Product Owner plaatst de userstories in een lijst voor het ontwikkelteam.
De Product Owner kan ervoor kiezen om eerst een complete epic voor te bereiden. Als het echter belangrijker is om bepaalde software eerst op te leveren kan het gebeuren dat userstories uit verschillende epics voorrang krijgen.

De prioriteiten van een Product Owner kunnen beïnvloed worden door:

• De prioriteiten van de opdrachtgever.
• De noodzaak om snel feedback te krijgen.
• Implementatieproblemen.
• Relaties tussen workitems (bijv. A wordt eenvoudiger als we eerst B doen).

Hoewel het de taak van de Product Owner is om prioriteit te geven aan de backlogitems doet hij dat niet alleen. Een goede Product Owner zoekt input en feedback van gebruikers, designers en de ontwikkelaars. Doel is om de werklast en de oplevering van het product optimaal te verdelen.

Hoe ziet een Product Backlog eruit (voor een fictief e-commerce project)?

Hier is een voorbeeld met verschillende soorten items, zoals je die ook in een echte backlog kunt vinden:

Epics / Hoog-niveau User Stories: 

• Gebruikersaccountbeheer: 

Eerste functies om een gebruiker toegang te geven tot de applicatie.
“Als klant wil ik een gebruikersaccount kunnen aanmaken en beheren, zodat ik mijn gegevens kan opslaan en mijn bestellingen kan volgen.”

• Productcatalogus: 

Functies waarmee een klant kan winkelen.
“Als klant wil ik producten kunnen zoeken, filteren en bekijken in de catalogus, zodat ik vind wat ik zoek.”

• Winkelwagen en Afrekenen: 

Tenslotte het ondersteunen van aankoop functies.
“Als klant wil ik producten aan mijn winkelwagen kunnen toevoegen en veilig kunnen afrekenen, zodat ik mijn bestelling kan plaatsen.”

Geprioriteerde User Stories (detailniveau onder de Epics): 

• Prioriteit 1 (Top):
• “Als klant wil ik een account kunnen aanmaken met e-mail en wachtwoord, zodat ik kan inloggen.”
• “Als klant wil ik producten kunnen zoeken op naam, zodat ik sneller kan vinden wat ik zoek.”
• Prioriteit 2:
• “Als klant wil ik producten kunnen filteren op prijs, zodat ik mijn budget kan beheren.”
• “Als klant wil ik mijn adres kunnen opslaan in mijn account, zodat ik deze niet elke keer opnieuw hoef in te voeren.”
• Prioriteit 3:
• “Als klant wil ik een overzicht van mijn vorige bestellingen kunnen zien, zodat ik mijn aankoophistorie kan raadplegen.”
• “Als klant wil ik gerelateerde producten kunnen zien bij een productpagina, zodat ik mijn keuzes kan verbreden.”

Bugfixes:

• “De filterknop voor prijs werkt niet correct; producten worden niet goed gefilterd.”
• “De inlogpagina toont een foutmelding bij het gebruik van speciale tekens in het wachtwoord.”

Verbeteringen:

• “Verbeter de laadtijd van de productpagina met 20%.”
• “Implementeer een ‘wishlist’ functie zodat gebruikers producten kunnen opslaan voor later.”

Belangrijk om te weten:

• Geprioriteerd: 

De items staan in volgorde van belangrijkheid, vaak gebaseerd op waarde, risico en afhankelijkheden. 

• Gedetailleerd: 

De meest urgente en belangrijke items zijn het meest gedetailleerd, terwijl de minder belangrijke items meer algemeen kunnen zijn. 

• Dynamisch: 

De backlog is nooit voltooid en evolueert continu met het product en de behoeften van de gebruikers. 

Bijhouden van de Product Backlog

Het is belangrijk om de Product Backlog regelmatig bij te houden, in gelijke tred met het programma. Product Owners moeten de Backlog vóór iedere iteratie-vergadering beoordelen. Ze moeten ervoor zorgen dat de prioriteiten correct zijn en dat de feedback van de laatste iteratie is verwerkt.  Zodra de Backlog groter wordt, moet de Product Owner de Backlog groeperen in workitems voor de korte en lange termijn. Userstories voor de korte termijn moeten volledig worden uitgewerkt voordat ze worden vrijgegeven.

Dit betekent dat complete userstories zijn opgesteld, de samenhang tussen het ontwerp en ontwikkeling duidelijk is en er schattingen van de ontwikkeltijd zijn gemaakt. Stories voor langere termijn kunnen een beetje vaag blijven. Het wel een goed idee is om een ​​ruwe schatting te krijgen van het ontwikkeltijd, dit helpt bij het stellen van prioriteiten. De schattingen veranderen zodra het team volledig inzicht heeft en start met de workitems voor de langere termijn.

De backlog fungeert als schakel tussen de Product Owner en het ontwikkelingsteam. De Productowner is vrij om op ieder moment andere prioriteiten toe te kennen aan workitems in de Backlog. Dat kan zijn vanwege feedback van opdrachtgevers, meer verfijnde schattingen en nieuwe requirements. Als de ontwikkeling eenmaal is gestart moeten de wijzigingen tot een minimum beperkt blijven. Wijzigingen storen dan het ontwikkelingsteam en hebben een negatieve invloed op focus, flow en moreel.

Backlog aandachtspunten

• Aan het begin van het project geeft de Product Owner prioriteiten aan de Backlog, maar past deze niet aan zodra feedback van ontwikkelaars en belanghebbenden binnenkomt.
• Het team beperkt zich tot workitems op de backlog die alleen klantgericht zijn.
• De Backlog wordt lokaal opgeslagen en niet gedeeld. Deelnemers ontvangen geen updates.

Hoe houdt de Product Backlog het team Agile?

Slimme Product Owners koesteren de Product Backlog van hun programma, waardoor dit een betrouwbaar en deelbaar overzicht is van alle deliverables van een project.

Gebruikers en ontwikkelaars zullen prioriteiten stellen. Door hierover te discussieren over wat belangrijk is, worden ieders prioriteiten gesynchroniseerd. Deze discussies horen bij de groepscultuur en zorgen ervoor dat de denkwijze over op het programma door iedereen wordt gedeeld.

De Product Backlog dient ook als de basis voor iteratieplanning. Alle workitems moeten worden opgenomen in de backlog: userstories, bugs, ontwerpwijzigingen, technische items, gebruikersverzoeken, evaluatie items, etc. Dit zorgt ervoor dat ieders workitems voor iedere iteratie zijn meegenomen in de algemene discussie. Teamleden kunnen vervolgens met een volledig overzicht met de Product Owner in overleg over de volgende iteratie.

Discussieer mee op LinkedIn.