Je hebt misschien weleens gehoord dat een agile product backlog DEEP hoort te zijn. Ik leg je in dit artikel uit wat dat betekent.

Vrijwel ieder agile project maakt gebruik van een product backlog. Hoe zo’n product backlog eruit zou moeten zien, zijn nogal wat misverstanden over.

In de Scrum Guide wordt de product backlog omschreven als:

“De Product Backlog is een levende, geordende lijst van wat nodig is om het product te verbeteren.”

De items op de product backlog worden meestal weergegeven als user stories.

Een product backlog is niet hetzelfde als een traditionele lijst met SMART requirements. Een goede product backlog is DEEP. Mike Cohn heeft de belangrijkste kenmerken van een product backlog samengevat in het acroniem DEEP.

Een goede product backlog is DEEP

De letters van DEEP staan achtereenvolgens voor:

D – Detailed appropriately

Dit wil zeggen dat de items op de product backlog het juiste detailniveau hebben. De user stories die in de komende sprint geïmplementeerd worden, zijn klein en de user stories die voorlopig nog niet aan de beurt zijn, zijn veel groter.

Het is onverstandig om allemaal gedetailleerde user stories op de product backlog te zetten. Dat is namelijk lastig te managen, is onoverzichtelijk en het leidt tot veel rework. En bovendien kost het inschatten en prioriteren van al die kleine user stories veel tijd.

Kortom te veel details op de product backlog is verspilling van tijd en energie (waste). Het veelgehoorde advies binnen agile luidt dan ook:

‘Add details at the last responsible moment’

E- Estimated

Hiermee wordt aangegeven dat de omvang van elk item op de product backlog ingeschat hoort te zijn. Het gaat daarbij om een relatieve schatting. En niet om de tijd die nodig is voor het implementeren van een user story.

Het team schat in hoe groot een user story is in vergelijking met een aantal referentie user stories. Bijvoorbeeld 1½ keer zo groot of 10 keer zo groot. Ieder user story krijgt hiertoe een aantal punten. Aangezien deze punten relatief zijn en daardoor geen grootheid hebben, worden ze meestal aangeduid als ‘story points’.

De schattingen zijn belangrijk omdat de product backlog onder andere dient als planningstool. In de product backlog is namelijk eenvoudig aan te geven welke user stories in een sprint en in een release meegenomen kunnen worden.

E – Emergent

Dit betekent dat een product backlog evolueert en dynamisch is. Dynamisch in de zin dat de items op de DEEP product backlog voortdurend meeveranderen met de actuele inzichten. De product backlog geeft dus op elk moment inzicht in hetgeen er nodig is om het product waardevol, concurrerend en beter te maken.

De product owner en het team passen de user stories, de prioriteiten en de schattingen voortdurend aan aan de laatste inzichten. Die inzichten veranderen doordat je steeds meer te weten komt over het product, de gebruikers, de omgeving en de technologie. En doordat de meningen en behoeften van de stakeholders aan voortschrijdend inzicht onderhevig zijn.

Hoe je dit in jouw praktijksituatie aanpakt, lees je in mijn e-book ‘Haal meer uit User Stories’. Daarin geef ik je het complete plaatje. Zodat jij je aandacht op de juiste dingen gaat richten en je in minder tijd meer resultaat boekt.

P – Prioritized

Dit geeft aan dat de items op de product backlog in volgorde van prioriteit staan. De user story met de hoogste prioriteit staat bovenaan en wordt in principe als eerste geïmplementeerd.

De product owner kent de prioriteiten toe, maar laat zich adviseren door stakeholders uit de business en door het team. Aspecten die meespelen bij het prioriteren van de user stories zijn: minimum viable product, businesswaarde, risico’s en afhankelijkheden.

Prioritering is essentieel voor het leveren van zo veel mogelijk business value. De product owner is immers verantwoordelijk voor het maximeren van de Return on Investment (ROI).

Nicole de Swart

Misschien vind je dit ook interessant

4 reacties

  • Tomas

    DEEP is interessant! Al voorzie is veel discussie over de “D” en dan vnl wat “appropriately” is. Zeker aangezien SCRUM / Agile geen echte traditie van requirement management kennen.

    Juist omdat requirements snel / vaak kunnen wijzigen (niet specifiek voor SCRUM / Agile trajecten overigens) is overzicht in het detail van de requirements noodzakelijk. Hierdoor voorzie ik toch dat de user stories tot op een zeker detailniveau uitgewerkt moeten zijn om deze wijzigingen -waar nodig- over de hele set aan user stories te kunnen doorvoeren. Bovendien heb je “approriate” detail ook nodig om goed te kunnen schatten.

    Vraag is dus wat is “appropriate”, anders dan het algemene adagio van “net genoeg”.

    • Nicole de Swart

      Tomas,
      Wat ‘appropriate’ is, qua detailniveau van een user story, hangt af van de prioriteit van die user story. Hoe hoger de prioriteit hoe meer details uitgewerkt moeten zijn. De user stories die (waarschijnlijk) in de eerst volgende sprint geïmplementeerd gaan worden, moeten genoeg details bevatten en zo klein zijn dat het team ze nauwkeurig kan schatten en in enkele dagen tot maximaal een week kan implementeren. Wanneer dit het geval is, verschilt per project en per team. Hier kom je achter door het team te vragen om de user stories te schatten. Bijvoorbeeld met planningpoker zie je meteen of de teamleden interpretatieverschillen hebben of details missen.

      ‘Appropriate’ betekent ook dat user stories die niet op (hele) korte termijn door het team opgepakt worden, weinig details bevatten en veel groter zijn. Juist om te voorkomen dat je ze iedere keer moet aanpassen als er gewijzigde inzichten zijn. Geen ‘voorraad’ met requirements opbouwen dus, maar pas uitwerken als het team ze nodig heeft. ‘Just in time’ requirements noemt met dat vaak.

  • Rick

    Persoonlijk gebruik ik liever INVEST dan DEEP, omdat je dan vanuit iets meer invalshoeken en aspecten een user story sprint ready probeert te maken. Nadeel is dan wel dat je hiermee meer tijd aan je refinements kwijt bent. Maar met name de T (Testable) en V (Valuable) uit het INVEST acroniem mis ik bij DEEP: het bepalen of een user story testbaar is (acceptatiecriteria?) en of deze businesswaarde vertegenwoordigt.

    • Nicole de Swart

      Ja, INVEST is ook een zeer handig acroniem. Je kunt ze ook beide gebruiken DEEP voor de product backlog en INVEST voor de user stories.

Geef een reactie