Wanneer is een Sprint afgerond?

Het komt vrij vaak voor dat een team aan het einde van een agile Sprint of iteratie nog onafgemaakt werk over heeft. Idealiter zou een team altijd elk item in de Sprint Backlog tijdens de Sprint afronden. Om verschillende redenen is dat echter niet altijd het geval. Dat brengt ons bij een aantal vragen, waar ik hieronder op in zal gaan:

• Wat moet er gebeuren met het betreffende Product Backlog Item?

• Moet het opgesplitst worden of meegenomen worden naar de volgende Sprint? Moet het team de punten voor de afgeronde delen van de Story meetellen bij de Velocity?

Is het item nog relevant?

Wanneer een Product Backlog Item aan het einde van een Sprint niet is afgerond, zou het eigenlijk terug moeten worden verplaatst naar de Product Backlog. Werk wordt nooit automatisch van de ene Sprint naar de volgende overgenomen.

Misschien ben ik bij dit onderwerp wat te pietluttig, maar het gaat mij erom dat elke Sprint begint met een bewuste beslissing van de Product Owner over waar het team aan gaat werken. Natuurlijk is het zeer waarschijnlijk dat de Product Owner wil dat het team het onafgemaakte werk uit de vorige Sprint in de nieuwe Sprint afrondt. Maar dit zou altijd een bewuste beslissing van de Product Owner moeten zijn.

(Even ter verduidelijking: ik zeg niet dat je jezelf extra werk moet bezorgen als je een tool gebruikt waarbij dat te ingewikkeld zou zijn. Ik zeg alleen dat werk niet automatisch naar de volgende Sprint wordt overgenomen. De Product Owner zou altijd moeten beslissen of het werk nog relevant is.)

Opsplitsen of meenemen naar de volgende Sprint?

Wanneer een Product Backlog niet volledig afgerond kon worden, vragen teamleden zich vaak af of ze het Product Backlog Item zo moeten laten (ook als er al een deel van de functionaliteit af is) of dat ze het moeten herschrijven zodat alleen het ontbrekende deel wordt beschreven.

Voorbeeld: Stel dat een team werkt aan een typische afdrukvoorbeeldfunctie voor een desktopapplicatie. Als het team alles heeft afgerond behalve de mogelijkheid om door de afzonderlijke pagina's terug te bladeren, kunnen de teamleden ofwel de originele User Story meenemen naar de volgende Sprint, ofwel een kleinere Story schrijven: „Als gebruiker wil ik terug kunnen bladeren wanneer het afdrukvoorbeeld wordt weergegeven."

Als de Story in de volgende Sprint wordt afgerond, zou ik voorstellen om haar gewoon te laten zoals ze is en haar niet te herschrijven. Iedereen kent de Story zoals die tot nu toe geschreven is. Als de Product Owner haar dus nog steeds belangrijk vindt, gaat ze ongewijzigd mee naar de volgende Sprint.

Mocht het resterende werk echter naar een latere Sprint worden verschoven, dan moet er een nieuwe Story worden geschreven die alleen het onafgemaakte deel van de functionaliteit beschrijft.

Onthoud: Als het werk in de volgende Sprint wordt afgerond, wordt de Story niet herschreven.

Krijgt het team punten voor de Velocity?

Ik neem graag een wat conservatief standpunt in als het gaat om de Velocity . Dat betekent dat een team alleen punten zou moeten krijgen voor werk dat ook echt helemaal af is. Dat betekent:

1. Als een onafgemaakt Product Backlog Item wordt meegenomen naar de volgende Sprint en daar wordt afgerond, dan zou het team in de oorspronkelijke Sprint geen punten daarvoor moeten krijgen. In plaats daarvan krijgt het team alle punten voor de Story in de Sprint waarin het werk daadwerkelijk wordt afgerond. Omdat ik sowieso voorstander ben van werken met een gemiddelde Velocity, egaliseert dit zich weer en is er geen risico dat de Velocity te hoog wordt ingeschat.

2. Anders is het wanneer het team de Story opsplitst en het resterende werk terug in de Product Backlog plaatst om er later aan te werken. In dat geval worden de punten voor het afgeronde werk aan het team toegekend. De teamleden moeten dan zo goed mogelijk inschatten hoeveel punten het afgeronde werk waard is. Ook al is de volledige Story nog niet af, kan het zijn dat het team alle oorspronkelijke punten voor de Story krijgt, want het is mogelijk dat de Story toch groter was dan gedacht. Dit zou niet voortdurend moeten gebeuren, maar af en toe is het prima.

Conclusie: Zoek altijd naar de oorzaak

Als er aan het einde van de Sprint nog onafgemaakt werk is, moet het team in de Retrospective altijd de tijd nemen om te onderzoeken of de oorzaak daarvan vermijdbaar was geweest. Soms is het gewoon pech of slechte timing; bijvoorbeeld wanneer een teamlid ziek wordt of er een probleem opduikt dat aan het begin van de Sprint niet te voorzien was. Het is echter altijd verstandig om na te denken over wat de oorzaak was en hoe je dat in de toekomst kunt voorkomen.

Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.

User Stories, Epics, Themes

We leggen het verschil tussen deze items uit.
=>User Stories, Epics, Themes

Een product ontwikkelen

Van idee tot realisatie met het Product Vision Board.
=>Product Vision Board

Wat zijn Story Points?

Ontdek waar je de inschattingen van je team kunt verbeteren.
=>Wat zijn Story Points?