fbpx

Product Backlog

Over het effectief gebruik van de Product Backlog

In dit artikel leggen we je uit wat de Product Backlog precies inhoudt. Om de context van dit zogenoemde Artefact volledig te begrijpen, is het prettig om eerst het Scrum Framework te begrijpen.

Wat is de Product Backlog?

De Product Backlog is een geordende lijst van de bestaande kennis van alles wat nodig is om het product te ontwikkelen en verbeteren. Het is dus een lijst met alle wensen, eisen, features, oplossingen, verbeteringen voor het product waar de Developers mee aan de slag gaan.

De Product Owner is verantwoordelijk voor het opstellen van deze lijst en het afstemmen met alle stakeholders wat prioriteit heeft. De lijst is dus een weergave van wat de klant echt wil, maar ook van dat wat echt nodig is (in termen van veiligheid of technische specificaties).

Product Backlog

Het gebruik 

De items in de Product Backlog zijn georganiseerd op volgorde van waarde: de waardevolste Product Backlog Items zijn in detail uitgewerkt en staan bovenaan de lijst. De User Stories die lager staan zijn minder waardevol op dit moment en zijn daarom ook nog niet geheel in detail uitgewerkt. We hebben dus liever focus op het daadwerkelijk realiseren van de meest waardevolle zaken in plaats van het verder uitdenken van de minder waardevolle zaken. Een belangrijk verschil tussen Agile werken en de Waterval methode.

De flexibiliteit 

De Product Backlog is geen statische lijst, maar is een levend document. Er kunnen altijd items aan toegevoegd, verwijderd of gewijzigd worden. Zo zal het voorkomen dat de Product Owner in overleg met de Stakeholders beslist dat bepaalde Product Backlog Items geen waarde meer hebben voor de klant of dat we door nieuwe inzichten wat meer aandacht zullen spenderen aan security of performance.

Kenmerken van een succesvolle Product Backlog:

  1. Altijd geprioriteerd. De Product Owner is verantwoordelijk voor het bijhouden van de backlog. Is deze slecht bijgehouden, dan weten stakeholders en het team niet wat er op hen afkomt. Het team wordt minder transparant en voorspelbaar. Simpel voorbeeld, gaat de PO van een slecht bijgehouden bord op vakantie voor een maand dan zal het team moeite hebben met de juiste dingen doen. Hier geldt voorkomen is beter dan genezen.
  2. De Product Backlog wordt niet voorafgaand aan de eerste Sprint volledig uitgewerkt, maar ontwikkelt zich gaandeweg gedurende het project.
  3. Gedetailleerd, maar met mate. Niet alle Product Backlog items hoeven tot in detail uitgewerkt te zijn. Een vuistregel is dat een Product Owner voor ongeveer twee á drie Sprints aan gedetailleerde Product Backlog items klaar heeft staan.
  4. Eén eigenaar. De Product Owner is de eigenaar van het Product Backlog. Niemand anders mag daar zomaar aan sleutelen. Als organisatie en als team vertrouwen we er op dat de PO dit zo goed mogelijk tracht te doen. De Scrum Master is er om te coachen waar nodig.
  5. Eén Artefact. De Product Backlog wordt op één plek bijgehouden en is zo volledig als alle inzichten die er zijn. Er zijn géén losse post-its of (digitale) boekjes met ideeën. Of erger, in het hoofd van de PO. Alles staat centraal uitgeschreven en transparant voor iedereen op één omgeving.

Product Backlog vs Sprint Backlog

De Product Backlog komt aan bod bij elke Sprint Planning. Dan zullen de teamleden besluiten welke taken meegenomen gaan worden in de volgende Sprint. De lijst met taken die daadwerkelijk meegenomen worden in een Sprint, noemen we de Sprint Backlog.