+31 35 543 1000 info@kza.nl

De Product Backlog

aug 25, 2016 | Agile, KZA Blogs

Het is een activiteit waar de Product Owner (PO) vaak veel tijd aan kwijt is; het vullen, prioriteren en bijschaven van de product backlog. Als je kijkt naar de rol van de Product Owner in een scrum project is hij degene die de verantwoordelijkheid draagt voor het maximaliseren van de business value die het ontwikkelteam levert. Daarnaast helpt de PO bij het identificeren en opstellen van requirements, bepaalt de PO

wanneer deze gebouwd en dus gereleased worden. Ook bepaalt de PO de lange termijn planning. En dit allemaal terwijl hij de belangen van alle stakeholders moet behartigen. Al deze taken en verantwoordelijkheden komen samen in het opstellen van de product backlog.

Het is dus belangrijk dat de product backlog goed gevuld en bijgehouden wordt maar hoe dan?

Begin hoog over! Voordat de backlog gevuld kan worden is er een globale planning nodig om te bepalen welke functionaliteit als eerste ontwikkeld moet worden en dus de hoogste prioriteit krijgt op de backlog. Dit noemen we roadmappen. Het te bouwen product wordt hierbij gesplitst in kleinere stukken samenhangende functionaliteit die ook wel epics genoemd worden. Uit deze epics kunnen dan de user stories worden onttrokken.

De PO kan waar nodig gebruik maken van expertise van anderen om uit deze epics de initiële user stories te definiëren. Denk hierbij aan eindgebruikers, ontwerpers en testers. De agile tester moet er voor zorgen dat de stories niet alleen testbaar zijn maar ook volledig genoeg zodat tijdens het ontwikkelproces zo min mogelijk vragen ontstaan binnen het team.

DEEP

Een handig handvat om meer body te geven aan de user stories is DEEP (Mike Cohn). DEEP staat voor Detailed appropriately, Estimated, Emergent en Prioritized. Wat betekent dat de stories het juiste detailniveau moeten bevatten, de grootte geschat moeten kunnen worden, dat ze kunnen veranderen en uiteraard geprioriteerd moeten zijn. Deze vier eigenschappen hangen sterk met elkaar samen. De rol van de agile tester is hier opnieuw een belangrijke; de brug slaan tussen business (PO) en de ontwikkelaars. Door het blijven stellen van vragen kan de agile tester een hechte samenwerking tot stand brengen tussen business en team.

Tijdens de backlog refinement kan het team samen met de PO bespreken wat de hoogst geprioriteerde stories inhouden en waar nodig deze aanvullen en bijschaven. Wanneer een team wil gaan plannen voor de volgende sprint zal de PO alle opmerkingen moeten hebben verwerkt en de backlog prioritering weer op orde hebben.

Desondanks het vaak moeilijk is voor ontwikkelteams om onduidelijke stories al op grootte te schatten kan dit wel erg nuttig zijn. Een grove schatting kan de PO helpen zijn backlog te prioriteren en verder dan 1 sprint vooruit te plannen. Let wel op dat de schatting die wordt gegeven ten alle tijden kan veranderen door voortschrijdend inzicht over user stories. De PO moet dus weten dat een planning die hierop wordt gebaseerd zo goed is als de schatting van het team.

Naast DEEP is er nog een handig acroniem om te bepalen of een user story klaar is om op te pakken; INVEST.

  • Independent: is een user story onafhankelijk te realiseren en te implementeren?
  • Negotiable: een user story moet bespreekbaar zijn.
  • Valuable: voegt hij waarde toe voor de klant?
  • Estimable: kan er een gedraging schatting gemaakt worden van het werk dat gedaan moet worden om de story te realiseren?
  • Small: is een story klein genoeg om op te pakken?
  • Testable: bespreek hoe er getest kan worden en hang hier acceptatiecriteria aan.

Door deze punten te bespreken kan een PO en/of het team effectief bepalen of de story in de volgende sprint gerealiseerd kan worden. Logischerwijs zal de agile tester het testbaar maken van een story belangrijk vinden maar daarnaast kan hij ook een coachende rol innemen bij het bepalen van de kwaliteit van een story. Deze communicatieve vaardigheden van een agile tester zijn ook zeer waardevol tijdens de ontwikkeling van een user story omdat documentatie niet altijd voorhanden in en veranderingen snel moeten worden verwerkt.

Naast user stories kunnen ook andere items op de product backlog terecht komen. Denk hierbij aan bevindingen, technische aanpassingen of klant wensen. Het belangrijkste blijft dat ze mee geprioriteerd worden en dat het ontwikkelteam weet wat er moet gebeuren om het item te realiseren.

Wil je nog meer tips en uitgebreidere info over hoe je als PO de backlog op orde kunt houden of hoe jij de PO hierbij kan helpen, lees dan ook “De product backlog Hoe ga je daar mee om?” (Kevin Bakker et al., 2016).