Product backlog management is belangrijk omdat een product backlog voortdurend aan verandering onderhevig is. “De Product backlog verandert voortdurend om duidelijk te maken wat het product nodig heeft om passend, concurrerend en bruikbaar te zijn. Als een product bestaat, bestaat de bijbehorende Product backlog ook”, is te lezen in de Scrum Guide.  

Bij effectief product backlog management zorg je ervoor dat de product backlog een overzichtelijke lijst van requirements (meestal in de vorm van user stories) blijft. De product backlog moet namelijk voor alle betrokkenen transparantie bieden. Dan ontstaat er geen misverstand over hetgeen 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 ordenen
  • het managen en actueel houden van de product backlog tijdrovend
  • de samenhang tussen de user stories niet inzichtelijk
  • the big picture al snel zoek

Is dit 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 agile team onnodig moeilijk. Het zorgt voor veel overbodig werk en de refinement meetings kosten extra tijd.

5 product backlog management tips

Wat kun je doen om de product backlog weer op orde te krijgen én te houden? Met de volgende 5 tips krijg je alleen actuele user stories en hebben ze de juiste omvang.

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. Het fundamentele verschil is namelijk dat:

  • Een traditionele baseline het gewenste eindresultaat beschrijft. De goedgekeurde requirements geven aan hoe het nieuwe systeem eruit moet komt te zien. Ze moeten daarom voldoen aan (de SMART) kwaliteitscriteria zoals eenduidigheid en volledigheid.
  • Een product backlog meer een actielijst is, 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 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 (epics) voor functies 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. Hoe hoger een user story op de product backlog staat, hoe eerder het ontwikkelteam hem gaat realiseren en hoe kleiner de user story daarom moet zijn.

4. Werk de product backlog elke sprint bij

Een product backlog is een levend product dat voortdurend van samenstelling verandert. Het is nodig om vrijwel elke sprint:

  • enkele user stories verder te detailleren
  • nieuwe inzichten in de backlog en user stories te verwerken 
  • de (tijdens de sprint review meeting) ontvangen feedback te verwerken
  • user stories die in de sprint opgenomen zijn naar de sprint backlog te verhuizen

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 hoort altijd de actuele stand weer te geven. Dat geldt dus ook voor user stories die eerder heel belangrijk werden gevonden en dat nu veel minder of niet meer zijn. Bijvoorbeeld omdat de focus verschoven is. 

Verwijder user stories die niet meer belangrijk zijn of al heel lang op de product backlog staan, gerust! Of als dat weerstand oproept is het misschien slimmer om ze te verplaatsen naar een andere lijst (waar je vervolgens niet meer naar kijkt ;-)).

Gaat er dan geen informatie verloren? Jawel, en dat is 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.

User stories en requirements die belangrijk genoeg zijn, komen 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.


Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts 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:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap