Follow Us on Twitter

Release Planning met Scrum

Gepubliceerd in

November 2007 - In plaats van traditioneel projectmanagement worden steeds meer software development projecten volgens een ‘agile’ methode zoals Scrum gemanaged. Er zijn verschillende zienswijzen op de betekenis van agile, maar een belangrijke overeenkomst is dat agile uitgaat van korte iteraties (2 tot 4 weken), waarbij aan het einde van elke iteratie de koers van het project bijgesteld kan worden aan de hand van de dan geldende inzichten.

Op deze manier worden beslissingen met betrekking tot features (binnen Scrum is een feature vaak een User Story) tot het laatst mogelijke moment uitgesteld, want dat is het moment dat de meeste informatie beschikbaar is. Toch is er wel degelijk behoefte aan een planningshorizon die verder ligt dan één iteratie (Scrum: Sprint), zodat bijvoorbeeld de inzet van mensen georganiseerd kan worden of tijdig de uiteindelijke release van de software gepland kan worden (promotie, marketing, sales, implementatie, etc..etc..).

Dat klinkt paradoxaal, maar in dit Whitebook zal ik laten zien dat het wel degelijk mogelijk is om in een Scrum project een betrouwbaar releaseplan op te leveren.

Velocity

Een Scrum software project realiseert software "User Story voor User Story" (er zijn ook alternatieven voor User Stories). Hierbij is het gebruikelijk om de belangrijkste User Stories (lees: met de meeste waarde voor de opdrachtgever) als eerste op te leveren. Aan het begin van een Sprint wordt de grootte van een User Story door het Team ingeschat. Dat kan in een willekeurige eenheid, maar in deze Whitebook ga ik uit van het schatten in story points. Stel, de opdrachtgever (Scrum: Product Owner) heeft de volgende lijst met User Stories samengesteld (Scrum: Product Backlog), waarop het team een eerste inschatting gedaan heeft:

User Story   Story Points
 A             3
 B             8
 C             5
 D            13
 E             8
 ...
 Z            21

In de eerste Sprint blijkt het Team User Story A, B en C opgeleverd te hebben. Totaal is er dan voor 3+8+5=16 story points opgeleverd. We zeggen dan dat "de Velocity van het Team 16 story points per Sprint is" (er zijn methoden om Velocity nauwkeuriger/betrouwbaarder te bepalen op basis van bv. gemiddelden, medianen en variantie over meerdere Sprints, maar dat valt buiten de scope van dit Whitebook).

Fixed date of fixed features?

Een software project kan op twee manieren gestuurd worden: op datum of op aantal features. Een project wat op datum gestuurd wordt, heeft een vooraf geplande einddatum. De beschikbare tijd tot deze einddatum begrenst het aantal Sprints. De maximale omvang van de softwarerelease wordt dan bepaald door het aantal Sprints met de Velocity te vermenigvuldigen.

 

Fixed date project

Fig 1, Fixed date project

Als de einddatum over een half jaar is, en één Sprint duurt 3 weken, dan kan het bovenstaande Team nog 8 Sprints doen (26 weken gedeeld door 3) en dus in totaal nog 128 story points aan User Stories realiseren (8 maal een Velocity van 16). Op de Product Backlog kan een denkbeeldige streep getrokken worden, zodanig dat het totaal aantal story points boven de streep zo dicht mogelijk bij de 128 ligt. Alle User Stories boven de streep worden dan in de release gepland, Stories onder de streep zullen pas in een volgende release terechtkomen.

Een project met "fixed features" wordt precies andersom benaderd: de denkbeeldige streep op de Product Backlog staat er dan al. Het aantal story points boven die streep moet gedeeld worden door de Velocity om het geschatte aantal benodigde Sprints te bepalen. Als de Product Owner bepaald heeft dat de release uit 200 story points moet bestaan, dan zal het bovenstaande team daar naar schatting 13 Sprints over gaan doen (200 gedeeld door 16).

Fixed features project

Fig 2, Fixed features project

Buffering

Elk project heeft met onzekerheden te maken met betrekking tot tijd en scope. Om een betrouwbaar releaseplan te maken, zullen deze onzekerheden in meer of mindere mate afgedekt moeten worden. Dat kan door buffers in te bouwen.

Buffers inbouwen kan op verschillende manieren. Bij een fixed date project is het zinvol om een feature buffer in te bouwen, omdat de einddatum vastligt. Hierbij wordt op basis van de Product Backlog een minimum aantal op te leveren User Stories afgesproken. De overige User Stories in de release kunnen als buffer gebruikt worden. Een andere bekende agile aanpak, DSDM, hanteert bijvoorbeeld als richtlijn dat maximaal 70% van het geschatte werk als must-have ingepland mag worden.

Bij een fixed feature project is het daarentegen zinvoller om een tijdsbuffer in te bouwen. De eenvoudigste manier om de lengte van deze buffer vast te stellen is door simpelweg een opslagpercentage op de schattingen toe te passen. Een wat lastigere, maar betrouwbaardere aanpak is om elke User Story twee keer te schatten: een "gemiddelde" schatting en een "worst case" schatting. De buffer wordt vervolgens bepaald door twee keer de standaardafwijking van de gemiddelden te bepalen (voor meer info, zie "Agile Estimating and Planning" van Mike Cohn).

Conclusie

Geen enkel project is 100% datum- danwel feature-gestuurd. Afhankelijk van de eisen en wensen van de Product Owner is een project vaak een gezonde combinatie van tijdsdruk en functionaliteit. Door slim gebruik te maken van User Stories, Velocity en de nodige buffers is het desalniettemin mogelijk om een plan op te stellen wat voor alle partijen voldoende betrouwbaar is om verdere beslissingen op te baseren.

Over de auteur

Martin Schapendonk is (agile) projectmanager voor Whitehorses en heeft ruim 9 jaar ervaring in vrijwel alle rollen in software development projecten. Naast Certified ScrumMaster is hij ook Prince2 Practitioner.

Referenties

 

 

Waardering:
 

Reacties

Beste Martin,

Een zeer duidelijk stukover hoe om te gaan met feature vs time binnen SCRUM.
1 ding wat voor mij niet geheel duidelijk is de door jou genoemde teamvelocity.

Je baseert namelijk de teamvelocity a.d.h.v. de gemaakte schattingen in de product backlog. Hoe wij de velocity inschatten gebeurd op 2 niveau's, namelijk:
1) Algemeen velocity: behaalde user stories van de product backlog.
2) team velocity: behaalde work items van de sprint backlog.

Dus stel:
Voor Sprint 1 heeft het team user story 1,2 en 3 gerealiseerd.
User story 1 bestaat uit 13 work items en komt op ong. 30 user stories uit.
User story 2 bestaat uit 15 work items en komt op ong. 35user stories uit.
User story 3 bestaat uit 11 work items en komt op ong. 25 user stories uit.
M.a.w.: algemene velocity is 16 maar het teamvelocity is dan 90.

Doordat je exacter weet wat je teamvelocity is (90) kan je tijdens de Sprint planning nog nauwkeuriger de user stories oppakken.

Hoe kijk jij hier tegen?

 

 

 

 

Hallo, Je inschatting op het 2e niveau is inderdaad nauwkeuriger, maar je kunt er alleen de omvang/einddatum van een release mee plannen als je alle user stories op je product backlog een "niveau 2" inschatting gegeven hebt. Als het een onevenredige inspanning is om je gehele product backlog op "niveau 2" te schatten dan is het handiger om je release op basis van de "niveau 1" inschatting te plannen. Groeten, Martin

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.