Wat is een Sprint Backlog?
De Sprint Backlog is een geordende lijst met alle te realiseren Backlog items voor de komende Sprint. Het is een selectie van alle Product Backlog Items, vaak User Stories, die in de komende Sprint worden opgepakt en worden afgerond. In de Sprint Planning Meeting worden de items verder uitgeschreven in taken.
Het is dus een overzichtelijke lijst van taken van Product Backlog items. Die in de Sprint Planning verder worden uitgewerkt in heldere taken. Met een detaillering dat het mogelijk is om de inhoud van de taak en de benodigde tijd goed te kunnen bepalen. In die mate dat de User Story kan worden afgerond.
Een vaak gehanteerde omschrijving van een Sprint Backlog is dat het een plan is waarin precies staat omschreven hoe het Sprintdoel wordt gehaald.
In de omschrijving staat dus hoe de taak moet worden uitgevoerd. De taak noteert het team op post-it’s die op het Board worden geplaatst. De Sprint Backlog laat dus alle te behalen items zien door deze onder te verdelen in taken. Een belangrijke stap, omdat hier wordt bepaald wat de noodzakelijke items zijn en hoe deze te gerealiseerd gaan worden zijn in deze Sprint.
De meeste teams maken een inschatting van elke taak hoeveel uur er nodig is om deze taak af te ronden.
Need to know
Een korte reminder over de Sprint Planning: Product Owner licht items toe, heeft prioriteiten toegekend, hanteert een volgorde, maar het Development Team bepaald welke items worden opgepakt en verder worden uitgewerkt.
Vanzelfsprekend worden ook de verbeterpunten uit de voorgaande Sprint Retrospective meegenomen. Dit helpt het team om zich te ontwikkelen volgens de gemaakte afspraken. Hierbij wordt vaak het volgende gehanteerd: minimaal één gemaakte afspraak, maximaal drie afspraken uit de Retrospective.
In tegenstelling tot wat vaak wordt gedacht is deze lijst pas compleet als de taken die moeten worden uitgevoerd ook echt zijn toegevoegd in de Sprint Planning. Dus alleen als een taak in de Sprint Backlog staat wordt deze ook daadwerkelijk uitgevoerd.
Een Sprint Backlog behoort tot de Scrum Artifacts, naast Product Backlog en Increments.
Voorwaarden aan de taken
Bij voorkeur is een taak niet langer dan 1 werkdag, hoe kleiner een taak gemaakt kan worden des te gemakkelijker is het om de taak af te ronden. Het streven moet altijd zijn om een taak zo te omschrijven dat er maximaal 1 werkdag voor nodig is, helaas zal dit echter niet altijd mogelijk zijn.
Taken gebaseerd op 1 werkdag bieden echter veel voordelen. De voortgang van taken, behorend bij een User Story, zijn dagelijks te volgen door het Team. Het helpt de flow van het Team te ondersteunen als elke dag de taken worden gerealiseerd. Want valt het namelijk direct op als de volgende dag een taak nog op het bord staat. Dan is er iets aan de hand. Het kan zijn dat er sprake is van een impediment, verkeerde inschatting of onverwachte oorzaken. Wat het ook is, het moet zo snel mogelijk duidelijk zijn wat er speelt en hierop actie worden ondernomen.
Kenmerken
Bij onderstaande kenmerken wijs ik er onder andere nog even op dat alleen het Development Team de Sprint Backlog mag aanpassen. Development Team maakt de Sprint Backlog en is eigenaar hiervan.
- De User Stories worden verder opgesplitst naar taken.
- Het Sprint doel moet worden gerealiseerd.
- De detaillering is dermate diep dat iedereen inzicht heeft in de voortgang richting het doel
- Gedurende de Sprint kan de Sprint Backlog worden aangepast door het Development Team, als onderdelen niet relevant (meer) blijken te zijn.
Hoe ziet het eruit?
Er zijn op internet veel sjablonen beschikbaar, ik toon hieronder een variant die gemaakt is in Excel.
Vanzelfsprekend kan je hiervoor ook een Scrum Board gebruiken, met post-its. Daarnaast hanteert men vaak een Burndown Chart om de voortgang bij te houden.