Wat is een ‘scrum backlog’?

De definitie van ‘scrum backlog’ of gewoonweg ‘backlog’ is: de lijst met alle taken die binnen het project vallen. Alles dat gedaan kan worden voordat de ‘definition of done’ (einde project) bereikt is.

Belangrijk gedeelte van die omschrijving is “alles dat gedaan kan worden”. Niet moet. Wanneer een taak in de backlog staat, betekent dat dat hij uitgevoerd kan worden. Het is een lijst met “willen we doen”, niet “moeten we doen”. Het is de plek waar je alle toffe ideeën (die gaandeweg ontstaan) en voortschrijdende inzichten (door analyse van gebruikersdata) verzamelt. Het is de verzamelbak, waaruit je per sprint kiest welke onderdelen er ontwikkeld gaan worden, en welke nog even moeten wachten tot een volgende sprint. Daarna worden taken pas definitief gemaakt en aan een tijdsplanning gekoppeld.

Onder andere dit kenmerk maakt dat een backlog, ook al bestaat die uit een lijst met taken, toch iets heel anders is dan een takenlijst.

Backlog ≠ takenlijst

Als je de definitie van een scrum backlog zo ziet, zou je bijna zeggen: “Da’s dus een to do lijstje”. Toch is het anders. Een taak die in de backlog komt te staan, voldoet namelijk aan een paar specifieke voorwaarden (die jouw takenlijst niet heeft):

• Taken moeten niet uitgevoerd worden, ze kunnen uitgevoerd worden.
• Als een taak niet bijdraagt aan de project goal (het einddoel), mag hij niet in de backlog.
• Op elk moment mogen er taken aan de backlog toegevoegd of van de backlog verwijderd worden, door voortschrijdend inzicht: het is een levend document.
• Aan elke taak wordt een waarde gekoppeld: wat voegt het toe aan het product? Is die er niet, dan hoort hij niet thuis in de scrum backlog.
• Aan elke taak wordt een prioriteit gekoppeld: welke taken krijgen voorrang?
• De product owner is de eindbaas van de backlog, zodat niet alle stakeholders en teamleden (met elk hun eigen belangen en prioriteiten) zich ermee kunnen bemoeien.
• Alleen de taken die gebruikt gaan worden in de eerstvolgende sprint(s) zijn verder gespecificeerd. De rest bevat slechts een kernachtige omschrijving. Uitbreiden van de omschrijving gebeurt pas tijdens de sprint, samen met de klant.
• De volgorde van taken staat op prioriteit. Prioriteit wordt doorgaans bepaald op basis van ‘toegevoegde waarde’, ‘kosten’ en ‘risico’s’. De Product Owner bepaalt de prioriteit.

De omschrijving van de scrum backlog is, zoals je ziet, vrij specifiek. Er bestaan een hoop ‘regels’ rondom het scrummen. Maar als je ze eenmaal kent, maken ze van elk project een foutloos en ideaal werkbaar proces.

Bijhouden = belangrijk!

Zoals je nu weet, is de scrum backlog een ‘levend document’. Dat is een belangrijk kenmerk. Het betekent dat de backlog telkens bijgeschaafd en bijgehouden wordt door het Scrum Team samen met de Product Owner. Er worden taken verwijderd, er komen taken bij, er worden taken bijgesteld of uitgebreid, prioriteiten veranderen, omschrijvingen veranderen.

Dat heet: ‘backlog refinement’.

In het begin, wanneer de scrum backlog opgesteld wordt, voegen het Scrum Team en de Product Owner alles aan de lijst toe wat in hen opkomt. Daarna is het de taak van backlog refinement om dat bij te schaven, als basis voor de eerstvolgende sprint(s).

En de belangrijkste regel daarvoor is (in de woorden van Frankwatching’s Anton Vanhoucke):

Backlog refinement  – het actualiseren van de backlog  – is net als de afwas. Je kan het beter wat vaker en korter doen, dan je na twee dagen door een aangekoekte berg vaat heenwerken.

Dagelijks even kort, bijvoorbeeld. Zo blijft het document actueel en compleet, te allen tijde. En dat is belangrijk voor die foutloosheid en werkbaarheid. Hoe actueler en completer de backlog, hoe beter het werkt.

De scrum backlog loop je zo gauw, elke middag, even door:

• Zijn er nieuwe taken die ingevoegd moeten worden?
• Hebben alle taken nog de juiste prioriteite en waarde?
• Zijn er bijzonderheden rondom taken?
• Welke taken staan in dienst van de aankomende sprint goal en/of van het project goal? De rest mag verwijderd.

​Dit kost, toegegeven, wat tijd. 5 tot 10% van de tijd van Scrum Team leden en tot wel 50% van de tijd van de Product Owner. Maar het is die tijd waard, omdat de investering altijd wordt terugverdiend in werkproductiviteit en -efficiëntie.

Als je de scrum backlog op deze manier netjes bijhoudt, zoals je de vaat zou bijhouden, dan staat alles namelijk netjes klaar om de Product Backlog op te stellen in de eerstvolgende Sprint Planning Meeting.

Heb je interesse in het opstellen van een goede backlog voor jouw business? Stuur ons hieronder een bericht om vrijblijvend wat af te spreken.