Hoe groot moeten Backlog Items in Scrum zijn?

Wanneer je in Agile of Scrum een Sprint of iteratie plant, is het belangrijk om na te denken over hoe groot de afzonderlijke taken zouden moeten zijn.

Je wilt geen te grote taken hebben

Het is moeilijk om de voortgang van het team te beoordelen als je met te grote taken werkt, want dan ben je gedwongen om in te schatten hoeveel procent van die taken al af is of hoeveel uren er nog over zijn.

En dat is echt niet makkelijk. Het wordt een stuk eenvoudiger als taken, zoals in Scrum, duidelijk aan een binaire status kunnen worden toegewezen: ofwel To Do ofwel Done . Maar dat betekent niet dat onze taken te klein moeten zijn.

Ook te kleine taken kunnen problemen veroorzaken

Een grotere coördinatie-inspanning is dan nodig, omdat er meer taken in de Iteratie zijn.
In de Iteration Planning is meer tijd nodig voor het opstellen van de taken.
Tijdens de Iteratie heb je meer tijd nodig voor het beheren en bijhouden van de taken.

Als de taken in een Iteratie dus niet te groot en niet te klein moeten zijn, wat is dan een passende grootte?

Er zijn twee goede richtlijnen. Gecombineerd kunnen deze twee richtlijnen je team helpen om taken met een goede grootte voor het Sprint Backlog of Iteration Backlog op te stellen.

Taken moeten binnen één dag af te ronden zijn

Stel je eens voor hoe geweldig het zou zijn als alle teamleden elke dag in de Daily Standup zouden kunnen zeggen: „Gisteren heb ik deze taak afgerond en vandaag ga ik deze nieuwe taak afronden."

Het is echter onrealistisch om te zeggen dat elke afzonderlijke taak precies één dag zou moeten duren. Daarom gaan we er simpelweg van uit dat de gemiddelde duur van de taken één dag zou moeten zijn. Sommige zullen iets langer duren, andere kosten minder tijd. Eén dag als streefdoel voor de gemiddelde taakgrootte nemen is echter een goed doel.

Maar zijn er dan op zijn minst redelijke boven- en ondergrenzen voor de grootte van de taken? Kan een team een taak van 10 dagen hebben, als dat wordt gecompenseerd door een paar taken van 5 minuten? Het antwoord daarop is richtlijn nr. 2.

Tasks zouden zich binnen een bereik van 1 uur tot 2 dagen voor de voltooiing moeten bevinden

Als je streeft naar zo'n gemiddelde taakgrootte, is het zinvol om enkele grenzen vast te stellen voor een geschikte omvang. Ik zou een bandbreedte van één uur tot twee dagen voorstellen.

Probeer taken te vermijden die naar schatting minder dan een uur duren. Een teamlid zal tijd nodig hebben om over de taak na te denken. De persoon zal misschien met iemand moeten praten voordat met de taak begonnen kan worden. Het kan ook zijn dat een taak van 10 minuten drie keer gedaan moet worden voordat alles eindelijk goed is, enzovoort.

Als je team daadwerkelijk iets heeft geïdentificeerd dat 10 minuten zou duren, geef dan gewoon een schatting van 1 uur af. Als die taak vervolgens in minder dan een uur wordt afgerond, compenseert dat de taken die te laat worden opgeleverd.

Ik stel een bovengrens van 2 dagen voor, niet omdat je veel taken van 2 dagen zou moeten hebben, maar omdat er af en toe taken kunnen zijn die niet binnen één dag afgerond kunnen worden.

Het is belangrijk om je hiervan bewust te zijn en grotere taken in het Iteration- respectievelijk Sprint Backlog toe te laten. Je wilt echter geen taken in het backlog die zo groot zijn dat teamleden worden ontheven van het harde werk om een probleem grondig te doordenken.

Grootte van Backlog Items

Dat ene optimale punt tussen taken die te groot zijn en taken die te klein zijn, bestaat echt. Als je je aan de twee hier genoemde richtlijnen houdt, help je je team om precies dat punt te vinden en succesvol te zijn met Agile en Scrum.

Dit artikel is afkomstig van Mike Cohn en door ons vertaald naar het Nederlands.

Het verschil tussen Story en Task

Ontdek hoe je Tasks onderscheidt van User Stories en nog grotere items in de Backlog.
=> Het verschil tussen Stories en Tasks

User Stories schrijven

Hier leer je hoe ik het liefst een User Story formuleer, zodat die zo eenvoudig mogelijk te begrijpen is.
=> Structuur voor User Stories

Niet alle taken in de Planning identificeren

Om te voorkomen dat er extra werk ontstaat, moeten Scrum Teams nooit alle toekomstige taken willen vastleggen.
=> Geen taken definiëren in de Planning