Wat is een backlog?

Een backlog is een geprioriteerde lijst van alle gewenste functies, verbeteringen, bugfixes en taken voor een softwareproject. Stel je voor dat een team een webshop bouwt: de backlog bevat alles van “winkelwagen toevoegen” en “betaalmethode toevoegen” tot “laadtijd van de startpagina verbeteren” en “foutmelding bij foutief e-mailadres herstellen”. De backlog is geen statisch document maar een levende lijst die voortdurend wordt aangevuld, herschikt en verfijnd naarmate het project evolueert. In agile methodologieën zoals Scrum vormt de backlog het centrale planningsinstrument dat de richting van het ontwikkelteam bepaalt. Een goed beheerde backlog zorgt ervoor dat het team altijd werkt aan de meest waardevolle taken en dat niets verloren gaat.

Soorten backlogs

In een agile omgeving — waarbij software in korte sprints wordt ontwikkeld — zijn er doorgaans twee niveaus van backlog: de product backlog en de sprint backlog. Beide spelen een essentiële maar verschillende rol.

Product backlog

De product backlog is de moederlijst van alles wat het product ooit zou kunnen bevatten. Hij wordt beheerd door de Product Owner, die verantwoordelijk is voor het prioriteren van de items op basis van zakelijke waarde, klantbehoefte en technische haalbaarheid. De product backlog is nooit “klaar”: zolang het product bestaat, worden er nieuwe ideeën, bugmeldingen en verbeterverzoeken aan toegevoegd. De items bovenaan de lijst zijn het meest uitgewerkt en klaar om opgepakt te worden; items onderaan kunnen nog vaag en ongedetailleerd zijn.

Sprint backlog

De sprint backlog is de selectie van items uit de product backlog die het team heeft gekozen om in de komende sprint — doorgaans twee weken — op te pakken. Tijdens de sprint planning selecteert het team de bovenste items van de product backlog en vertaalt die naar concrete taken. De sprint backlog is het eigendom van het ontwikkelteam: zij bepalen hoe ze de geselecteerde items aanpakken en kunnen de sprint backlog gedurende de sprint aanpassen als omstandigheden veranderen.

Wat staat er in een backlog?

Backlog-items kunnen verschillende vormen aannemen, afhankelijk van de methodologie en het type werk. In agile projecten zijn user stories de meest gebruikte notatie.

User stories

Een user story beschrijft een gewenste functionaliteit vanuit het perspectief van een eindgebruiker. De standaardformule is: “Als [type gebruiker] wil ik [actie] zodat [waarde].” Bijvoorbeeld: “Als webshopbezoeker wil ik producten kunnen filteren op prijs, zodat ik snel vind wat ik zoek.” Deze formulering dwingt het team om na te denken over het doel achter de functie, niet alleen de technische implementatie. Bij elke user story horen acceptatiecriteria: meetbare condities waaraan de implementatie moet voldoen voordat de story als voltooid wordt beschouwd.

Epics en thema’s

Grote functionele gebieden worden samengevat in epics: brede beschrijvingen van omvangrijke functies die te groot zijn om in één sprint te implementeren. Een epic zoals “Checkout-ervaring verbeteren” kan worden opgesplitst in meerdere kleinere user stories. Thema’s zijn nog abstracter en groeperen epics die bijdragen aan een overkoepelend strategisch doel, zoals “mobiele gebruikerservaring optimaliseren”.

Bugmeldingen en technische taken

Naast user stories bevat de backlog ook bugmeldingen — fouten die moeten worden opgelost — en technische taken of spikes. Een spike is een tijdgebonden onderzoekstaak om een technische vraag te beantwoorden, zoals het evalueren van twee verschillende databasetechnologieën. Technische schuld — werk dat is uitgesteld om sneller te kunnen leveren — vindt ook zijn weg naar de backlog als technische taak.

Backlog refinement: de lijst scherp houden

Backlog refinement, ook wel grooming genoemd, is het regelmatige proces van het verfijnen, uitbreiden en herprioriteren van de backlog. Typisch besteedt een agile team 10% van zijn sprinttijd hieraan. Tijdens refinement-sessies bespreekt het team de komende backlog-items: zijn de user stories duidelijk genoeg? Zijn de acceptatiecriteria volledig? Is de schatting realistisch?

Story points en inschatting

Teams schatten de omvang van backlog-items in met story points: een relatieve maatstaf voor complexiteit en inspanning. In plaats van uren te schatten — wat notoir onnauwkeurig is — vergelijkt het team items met elkaar. Een eenvoudig formulierveld krijgt misschien 1 story point; een complex zoekalgoritme misschien 13. De meest gebruikte schaal is de Fibonacci-reeks (1, 2, 3, 5, 8, 13, 21), omdat grote items inherent onzekerder zijn en die onzekerheid wordt weerspiegeld in de grotere stappen bovenaan de schaal.

Een gezonde backlog: do’s en don’ts

Een goed onderhouden backlog is het verschil tussen een gefocust, productief team en een team dat zich verliest in eindeloze discussies over prioriteiten.

• Do: prioriteer continu. De backlog verandert voortdurend; herprioriteer regelmatig op basis van nieuwe inzichten, klantfeedback en zakelijke doelstellingen.
• Do: houd items klein en specifiek. Grote, vage items leiden tot discussies en vertragingen. Splits epics tijdig op in hanteerbare user stories.
• Don’t: alles bewaren. Een backlog met honderden items die al jaren onaangeroerd staan, is een teken van gebrekkig beheer. Verwijder items die niet langer relevant zijn — dat heet backlog pruning.
• Don’t: de backlog buiten de Product Owner om aanpassen. Iedereen mag ideeën aandragen, maar de Product Owner is de poortwachter die beslist wat in de backlog komt en welke prioriteit elk item krijgt.

Conclusie

Een backlog is de geprioriteerde lijst van alles wat een team wil bouwen, verbeteren of oplossen in een softwareproject — het hart van agile planning. Door de product backlog te scheiden van de sprint backlog en regelmatig te verfijnen, houdt het team overzicht en focus op de meest waardevolle taken. Een gezonde backlog is nooit statisch: hij groeit mee met nieuwe inzichten, wordt regelmatig opgeschoond en weerspiegelt altijd de huidige prioriteiten van de organisatie. De Product Owner speelt een cruciale rol in het bewaken van die prioriteiten en het vertalen van zakelijke doelstellingen naar concrete, uitvoerbare items. Begin jij met agile werken? Dan is het opstellen en verfijnen van een heldere backlog de eerste en meest impactvolle stap die je kunt zetten.

Veelgestelde vragen

1. Wie is verantwoordelijk voor het beheren van de backlog?

   De Product Owner is primair verantwoordelijk voor de product backlog: hij of zij stelt prioriteiten, voegt items toe en verwijdert verouderde items. Het ontwikkelteam draagt bij door items in te schatten en technische risico’s te signaleren. De Scrum Master faciliteert het refinementproces.

2. Hoe groot mag een backlog zijn?

   Er is geen vaste maximumomvang, maar een te grote backlog — met honderden items — wordt onbeheersbaar. Een vuistregel is dat de bovenste twee tot drie sprints goed uitgewerkt en geprioriteerd zijn; items verder in de backlog mogen nog grover zijn. Verwijder items regelmatig als ze al lang niet zijn opgepakt en geen strategische relevantie meer hebben.

3. Wat is het verschil tussen een backlog en een to-dolijst?

   Een to-dolijst is een vlakke verzameling taken zonder expliciete prioritering of structuur. Een backlog is geprioriteerd, bevat context over de waarde van elk item (via user stories), heeft schattingen en wordt actief beheerd door een verantwoordelijke persoon. De backlog stuurt de langetermijnrichting van een team; een to-dolijst is puur operationeel.

4. Hoe pak je backlog refinement aan?

   Plan een vaste, korte sessie — doorgaans 60 tot 90 minuten per sprint — waarbij de Product Owner de komende items toelicht en het team vragen stelt, schattingen geeft en acceptatiecriteria aanscherpt. Zorg dat de bovenste twee sprints altijd klaar zijn om te plannen, zodat je sprint planning soepel verloopt.

5. Mag een team tijdens de sprint items toevoegen aan de sprint backlog?

   In principe is de sprint backlog na de sprint planning vastgesteld en wordt die niet meer gewijzigd, tenzij er een dringende omstandigheid is. Het toevoegen van items gedurende de sprint verstoort het sprintdoel en de capaciteitsplanning. Nieuwe inzichten en verzoeken gaan altijd eerst naar de product backlog, waarna de Product Owner ze prioriteert voor een volgende sprint.