Wat is een Product Backlog Item (PBI) in Scrum?

Wanneer je met Scrum werkt, kom je al gauw met heel wat afkortingen in aanraking. Je typt en zegt sneller “PO” dan voluit “Product Owner”. En in een Daily Scrum is het eenvoudiger om in een langdradig gesprek “ELMOOOOO” te roepen (kort voor Enough, Let’s Move On) dan in te moeten breken en te zeggen “oke, hier praten we nu al heel erg lang over, zullen we doorgaan?”. In deze blog staat een andere afkorting centraal, PBI: Product Backlog Item, ook wel eens “item”, “werkitem”, “ticket”, “issue” en “user story” genoemd.

Wat is een Product Backlog Item?

De Product Backlog is de voorraadlijst, waarop het werk dat nodig is om de Product Goal te behalen, wordt vastgelegd en geprioriteerd (Scrum.org, 2020). Dat werk kan op verschillende manieren worden beschreven, bijvoorbeeld als taken, vage ideeën, user stories, of problemen die opgelost moeten worden. Elk los item dat op een Product Backlog staat, noemen we een Product Backlog Item.

Een Product Backlog Item is dus werk dat op de Product Backlog staat. Door alle PBI’s zo klein en onafhankelijk mogelijk te maken, wordt het gemakkelijker om te prioriteren vanuit waarde. Als je in grote ideeën praat, kom je al snel tot de conclusie dat alle ideeën gerealiseerd moeten worden om tot een goed product te komen. Maar vaak bestaan grote ideeën uit verschillende kleinere onderdelen.

Als je op dat kleinere niveau over het werk na gaat denken, is de kans groot dat je niet letterlijk álles hoeft te doen. Het grote voordeel van werken met Product Backlog Items is dat je meer inzicht krijgt in al die kleine onderdelen, en daardoor gerichte keuzes kunt maken: wat doen we wel, wat (nu) niet?

Stel dat je als doel hebt om een nieuw pretpark te realiseren. Alles wat daarvoor moet gebeuren kun je ordenen en prioriteren op een Product Backlog. Denk hierbij aan de verschillende attracties, horeca, decoratie, afspraken met overheden en andere partijen, diverse shows, et cetera. Elk afzonderlijk stukje werk is een Product Backlog Item: de draaimolen, een achtbaan, een restaurant, een snackbar, een meertje, afstemming met een wethouder, de avondshow, en ga zo maar door.

Waaruit bestaat een Product Backlog Item (PBI)?

Om optimaal gebruik te maken van het idee achter PBI’s, helpt het om bij elk item te beschrijven wat ermee bedoeld wordt, wat de toegevoegde waarde van dit specifieke stukje werk is, hoeveel werk het – ongeveer – is, en wat de prioriteit is ten opzichte van andere PBI’s.

Beschrijving en waarde

Product Backlog Items beschrijven wat nodig is om het Product Goal te behalen, niet hoe dat gedaan moet worden. Om tot de meest waardevolle oplossingen te komen, helpt het als het volledige team begrijpt wat de toegevoegde waarde is. Als je een pretpark bouwt voor tieners, heeft een draaimolen een heel andere waarde dan een achtbaan.

Prioriteit van een PBI

Op basis van de toegevoegde waarde kun je vervolgens prioriteren. Door te prioriteren op basis van waarde voorkom je dat de eerste sprints verloren gaan aan voorbereidend werk. Hoe eerder je kunt valideren dat je aan de juiste oplossing werkt, hoe gerichter je in latere sprints te werk kunt gaan. Je wil dus eerst valideren dat tieners überhaupt behoefte hebben aan een pretpark. Dat gaat waarschijnlijk makkelijker met de achtbaan dan met een draaimolen.

Inschatting van de omvang

Elk Product Backlog Item zou binnen één sprint opgeleverd moeten kunnen worden. Als je eraan begint, wil je het werk namelijk ook afronden en valideren. Daarvoor heb je een idee nodig van de omvang van het werk. Het toekennen van Story Points is een praktische manier om binnen enkele sprints een goed beeld te hebben van de hoeveelheid werk die je in een sprint aan kunt. En bijkomend voordeel: als je weet hoeveel werk een PBI is, maakt dat het prioriteren ervan ook weer eenvoudiger.

Wie bepaalt de Product Backlog Items?

PBI’s staan op een Product Backlog en de Product Backlog wordt beheerd door de Product Owner. De Product Owner bepaalt welke wensen, ideeën en werkzaamheden wel en niet op de Product Backlog komen. Pas als werk op de Product Backlog wordt geplaatst, wordt het een Product Backlog item. De Product Owner bepaalt dus de Product Backlog Items.
De Product Owner kan dat echter niet alleen doen, maar werkt daarvoor intensief samen met alle verschillende stakeholders en de Developers. Wensen en behoeftes van eindgebruikers zijn de belangrijkste bron voor een Product Owner. Maar iedereen die ideeën of suggesties heeft, kan deze bij de Product Owner aandragen. Uiteindelijk bepaalt de Product Owner of het inderdaad relevant werk is. Zo ja, dan wordt het een Product Backlog Item.

Wat is het verschil tussen een PBI en User Story?

Het belangrijkste doel van Product Backlog Items, is beschrijven welk werk gewenst is en waarom dat waardevol is. Voor alle PBI’s is het handig om in één oogopslag te kunnen zien van wie de wens afkomstig is, wat de wens is, en waarom dat relevant is. Dat is precies wat een User Story beschrijft: als , wil ik , zodat ik.

User Stories zijn dus een praktische manier om een Product Backlog Item te beschrijven. Maar niet elke PBI hoeft een User Story te zijn. Dat heeft twee redenen:

1. De Product Backlog is altijd in ontwikkeling. Items die nog heel groot of vaag zijn, kunnen ook in steekwoorden beschreven zijn. Wat begint als “kassa”, kan na een refinement sessie uitgroeien tot een User Story die beschrijft wie een kassa wil en waarom.
2. Niet voor alle soorten werkzaamheden is het relevant om ze als User Story te beschrijven. “Handleiding schrijven voor het gebruik van de kassa” kan bijvoorbeeld duidelijke genoeg zijn.

Een User Story is dus een van de vele vormen van Product Backlog Items. Een User Story is wel altijd een Product Backlog Item, maar niet elk Product Backlog item hoeft een User Story te zijn. Vergelijk het met het dierenrijk: de Product Backlog is de verzameling van alle soorten dieren. Alles op de Product Backlog is dus een dier. Sommige van die dieren zijn leeuwen. Elke leeuw is een dier, maar niet elk dier is een leeuw.

Ben jij Product Owner of werk jij met Scrum en ben je opzoek naar meer theory, diepgang of praktische hulp? Neem dan contact op via info@agilescrumgroup.nl of 020 – 2614 195 en één van onze constulants helpt je graag verder.

Ook interessant:

• De 9 Kanban values als fundament
• 5 voorbeelden van Agile werken in de praktijk (non-IT)
• Wat is een Kanban Master?
• Starten met Scrum: hoe pak je dat aan?

Bronnen:

Over de auteur: Dennis Dielissen

Dennis is Agile Coach en trainer. Hij heeft een passie voor producten en diensten waar mensen écht op zitten te wachten. Vanuit zijn expertise in innovatie management en praktijkervaring als Product Owner, helpt hij teams om op een Agile manier succesvolle oplossingen te ontwikkelen. Dit doet hij voornamelijk door focus aan te brengen in de werkzaamheden en rollen, waardoor kwaliteiten beter tot hun recht komen.