Een product backlog is een geprioriteerde en overzichtelijke lijst van nog uit te werken en te implementeren requirements. Het is bedoeld als transparante opsomming, zodat alle betrokkenen weten wat er de komende tijd gerealiseerd gaat worden.

Maar de praktijk is vaak anders!

De product backlog bevat vaak tientallen kleine gedetailleerde user stories.

En daardoor is:

  • het lastig en veel werk om de vele user stories te prioriteren
  • het managen en actueel houden van de product backlog tijdrovend
  • de samenhang tussen de user stories niet inzichtelijk
  • the big picture al snel zoek

Herkenbaar? ….dan ben je niet de enige. Er is zelfs een naam aan gegeven: ‘story card hell’.

Met zo’n product backlog maak je het jezelf en het projectteam onnodig moeilijk. Het zorgt voor veel overbodig werk en de refinement meetings kosten extra tijd. Ik vertel je daarom graag wat je kunt doen om de product backlog weer op orde te krijgen.

5 tips voor het maken van een super effectieve product backlog:

1. Realiseer je dat een product backlog niet hetzelfde is als een traditionele baseline

De baseline met goedgekeurde requirements die we kennen uit het waterval tijdperk is niet te vergelijken met de product backlog binnen agile.

  • Een traditionele baseline beschrijft het gewenste eindresultaat. De goedgekeurde requirements geven aan hoe het nieuwe systeem eruit moet komt te zien. Ze moeten daarom voldoen aan kwaliteitscriteria zoals eenduidigheid en volledigheid.
  • Een product backlog is meer een actielijst, een lijst met nog uit te voeren werk. De requirements moeten nog verder gedetailleerd en gevalideerd worden. Je valideert ze namelijk achteraf en indirect met behulp van werkende software.

2. Speel met de omvang van de user stories

User stories (of PBL-items in een andere vorm) kunnen net als traditionele requirements groot of klein zijn. Ze hebben bewust geen vast omvang. Op de product backlog wil je namelijk user stories van verschillende omvang hebben.

Grote user stories (d.i. epics) voor features die later pas gerealiseerd worden. Middelgrote user stories voor functies die over enkele maanden aan de buurt zijn en kleine gedetailleerde user stories die het ontwikkelteam de komende 2 á 3 sprints gaat oppakken.

3. Definieer user stories top down

Een product backlog bevat in eerste instantie alleen epics. Alleen van een epic die binnen afzienbare tijd gerealiseerd gaat worden, splits je het belangrijkste deel af en maak je een andere (middelgrote) user story van. Dit herhaal je om van de middelgrote, kleine user stories te maken.

Zo krijg je een dynamische product backlog met user stories van verschillende omvang. De omvang van een user story is afhankelijk van zijn prioriteit en dus van het moment waarop het ontwikkelteam hem gaat realiseren.

4. Werk de product backlog elke sprint bij

Een product backlog is een levend product dat voortdurend van samenstelling verandert. (Vrijwel) elke sprint:

  • detailleer je user stories
  • splits je kleinere user stories af
  • verwerk je (eventuele) nieuwe inzichten
  • verwerk je de (tijdens de sprint review meeting) ontvangen feedback
  • verhuizen de user stories die in de sprint opgenomen zijn naar de sprint backlog

Als de product backlog enkele sprints achter elkaar ongewijzigd blijft, is dat een sterk signaal dat er iets niet goed gaat. Waarschijnlijk is de aanpak dan grotendeels traditioneel georiënteerd.

5. Durf stories van de product backlog af te halen

De product backlog geeft altijd de actuele stand weer. Dat geldt dus ook voor user stories die men belangrijk vond en dat nu veel minder blijken te zijn. Verwijder die user stories gerust! Of verplaats ze naar een andere lijst (waar je vervolgens nooit meer naar kijkt 🙂 ) als dat weerstand oproept.

Gaat er dan geen informatie verloren? Jawel, en dat ik precies de bedoeling!

Je wilt de product backlog namelijk handzaam en overzichtelijk houden. Een product backlog met veel (gedetailleerde) user stories heeft bij een agile werkwijze meer nadelen dan voordelen. Het is onnodige ballast en maar zeer de vraag of die requirements over een paar maanden nog relevant zijn.

Zo ja, dan komen die requirements (user stories) ongetwijfeld opnieuw op tafel tegen de tijd dat ze prioriteit hebben. En zo niet, dan zijn er kennelijk andere dingen belangrijker.

 

Laat me weten of deze tips je helpen bij het effectiever maken van de product backlog. Welke tips pas je al toe of ga je uitproberen? Ik kijkt uit naar je reactie hieronder.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book Vliegende start als agile analist

Met 25 do's en dont's voor agile requirements en eens per maand een agile requirements tip

Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Share This