Een product backlog moet altijd maar ongeveer 50 items bevatten

Hierbij maar eens een provocerend blogje met een provocerende titel. Het is een idee dat bij mij al een poosje borrelt en dat ik maar eens opschrijf om er feedback op te krijgen. Misschien zit ik er wel helemaal naast, maar dat wordt dan wel duidelijk uit de reacties.

Ik zie vaak hele grote, lange product backlogs met honderden items erin, waarin men met grote moeite overzicht behoudt. Om dat overzicht te krijgen worden dan allerlei levels toegevoegd, thema’s, epics, stories, of nog meer niveaus.

Volgens mij is dat allemaal niet nodig, sterker nog, volgens mij is het fout en een teken van nog steeds behoorlijk waterval werken.

Een Product Backlog met 50 items is genoeg!

Dat zit zo.

De top van de backlog, het werk voor de komende 2 of 3 sprints, moet mooie kleine, heldere items bevatten. In mijn ervaring doen de meeste teams ongeveer 6-10 items per sprint, dus dat geeft de eerste 25 of zo items.

Daaronder hoeft het allemaal niet zo precies en zo klein te zijn. Het zijn grotere brokken die later wel in stukjes gehakt worden als ze bijna in een sprint worden opgepakt.

Nu al in stukjes hakken is niet slim. Het zou zomaar kunnen zijn dat we dit item helemaal niet gaan oppakken. De klant wil misschien een andere kant op, of we verzinnen een heel andere technische oplossing. Agile zijn betekent dat je zoveel mogelijk openstaat voor dit soort veranderingen. Alles vast helemaal opknippen en uitwerken zorgt ervoor dat je al snel denkt: “dit moeten we echt zo uitvoeren, daar is al zo veel voorbereiding in gestoken”.

Onder die 3 sprints met kleine items (zeg van 1-8 story points groot) komen dus grotere items. Rond sprint 3-5 in de backlog zijn ze nog niet zo heel groot, 13-21 punten groot. Maar daaronder zijn het grotere brokken, 40-100 punten groot.

De hele backlog van 50 items vertegenwoordigt dus werk voor een heel jaar. Maar vooraf uitwerken is een vorm van waterval denken.

Herkenbaar? Mee eens? Ik hoor jullie reacties graag!

7 antwoorden
  1. Koen
    Koen zegt:

    Hoi André,

    leuke prikkelende blog. Wat mij opvalt is dat het nog niet zo makkelijk is voor veel teams en product owners om ooit bedachte stories weer van de backlog te verwijderen. In Utopia denk ik dat je gelijk hebt, en in de organisatie waar ik werk is de transitie nog steeds in de begin fase. Of dit oorzakelijk is of een gevolg, daar laat ik me niet over uit.

    Ik denk dat veel organisaties nog in transitie zijn (en hopelijk zullen blijven) waarbij dit inzicht mogelijk nog komt. Startup zullen mogelijk een product backlog hebben die meer overeenkomt met het ideaal beeld, al heb ik daar nog geen ervaring mee.

    Overigens, zolang het team niet teveel gehinderd wordt door de omvang van de backlog, en de PO ook niet, zie ik in een product idee archief ook geen issue.

    Beantwoorden
    • André Heijstek
      André Heijstek zegt:

      toch denk ik dat items verwijderen wel erg nuttig is (en Henrik Kniberg noemt ‘nee’ durven zeggen niet voor niets als de belangrijkste skill voor een PO). Door de lijst klein te houden heeft de PO veel meer overzicht en kan gemakkelijker een bewuste beslissing genomen worden om dingen eerst of juist later te doen. Als er veel items op de lijst staan word je psychologisch gehinderd om daar bewust over na te denken, volgens mij

      Beantwoorden
  2. Jean
    Jean zegt:

    Mijn tip zou zijn om een backlog te maken die prullenbak heet en daar alles in te stoppen wat meer dan tien sprints oud is.

    En dan ben ik benieuwd hoe vaak je team uit de prullenbak eet.

    Beantwoorden
    • Gertjan Kruiger
      Gertjan Kruiger zegt:

      Ik heb een vergelijkbare oplossing toegepast.

      Toen ik met de klus begon, hadden we hadden een backlog met daarop ca. 400 stories. De oudste story stond er al 2,5 jaar. Logisch dat daar genoeg stories bij waren die niemand (meer) begreep. De PO was huiverig om stories ‘zomaar’ te sluiten. Na een maand kreeg ik de PO overtuigd van het nut om alle stories met een updatedatum van meer dan 1 jaar geleden te sluiten. Het liefst had ik deze termijn nog korter gesteld, maar dit waren er in ieder geval ca. 200 minder.

      De volgende ‘opschoonslag’ hebben we anders aangepakt: van alle 200 stories hebben we ingeschat of deze story nog wel relevant was. Uiteindelijk bleek dit voor ca. 150 stories niet (meer) het geval. Deze stories hebben we op de backlog gelaten, maar in een aparte ‘bak’ neergezet. We hebben iedere mogelijke stakeholder geinformeerd dat we deze bak zouden legen. Dit leverde 2 of 3 reacties op en 2 maanden later hebben we ook deze 150 stories kunnen verwijderen.

      Reesultaat: ca. 50 stories over.

      Toch was ik nog niet tevreden. De heersende mentaliteit was namelijk dat als iets op de backlog stond het ooit wel een keer opgepakt zou worden (zie ook reactie Ivo hieronder). Dit waren de diverse stakeholders vanuit het verleden gewend. Ook voor de PO was het makkelijk om ‘zet maar op de backlog’ te zeggen en ondertussen zijn eigenlijk koers te volgen, i.p.v. de discussie aan te gaan. Langzaam maar zeker zie ik dit veranderen. Als ik zo terug kijk denk ik dat dit komt doordat we vaak hebben uitgelegd hoe we werken, transparant zijn geweest over de keuzes/prioriteiten en altijd waarde zijn blijven leveren.

      Beantwoorden
  3. Ivo ten Kate
    Ivo ten Kate zegt:

    Hallo André, eens en heel herkenbaar. Een Product Backlog is geen vergaarbak van items die misschien gedaan worden, maar een lijst van items die daadwerkelijk door het Development team worden opgepakt. Essentieel is dat de PO “nee” zegt in plaats van “lage prio, maar we zetten het op de backlog.” Het aantal (50) is een mooie richtlijn, maar het hangt wel af van de omgeving en fase in de transitie.

    Beantwoorden
  4. Rick van Teylingen
    Rick van Teylingen zegt:

    Hey André,

    Ik ben het er helemaal mee eens, ik denk dat bij grote hoeveelheden backlogitems nog steeds in oplossingen wordt gedacht, terwijl je die oplossing pas moet gaan bedenken zodra het item richting de bovenkant van de lijst gaat.

    Beantwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site wordt beschermd door reCAPTCHA en GooglePrivacy PolicyenServicevoorwaarden toepassen.

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.