Gezekerd van rots afdalenHet management en de business willen graag zekerheid. Ze willen weten wanneer welke features opgeleverd worden en of dat allemaal lukt voor de deadline.

Zekerheid is in een complexe omgeving niet te geven! Dat kan agile niet en dat kunnen traditionele aanpakken niet. Onzekerheid is nu eenmaal inherent aan complexe omgevingen. In veel organisaties houden managers echter vast aan de schijnzekerheid van traditionele planningen.

Agile belooft geen zekerheid. Wat agile wel biedt is voorspelbaarheid!

Voor een voorspelbaar ontwikkelproces zijn betrouwbare schattingen van de omvang van de user stories nodig. Dat is noodzakelijk om:

  • De sprints voorspelbaar te maken, zodat het ontwikkelteam de geplande stories in minimaal 80% van de sprints oplevert. Hiermee bouw je tevens vertrouwen op in het team en in de agile aanpak.
  • De verwachtingen van de business en klanten te managen. Dat doe je door aan te geven wanneer je bepaalde functionaliteit verwacht op te leveren.
  • Inzichtelijk te maken of je de deadline van het project gaat halen, of in agile termen gezegd wat het team binnen de gestelde deadline kan opleveren.

Betrouwbare schattingen

Je weet vast wel dat een product backlog een geprioriteerde lijst is van de items/user stories die nog gerealiseerd moeten worden. Weet je ook dat de omvang van ALLE user stories op de product backlog ingeschat behoort te zijn? Dat wil zeggen dat bekend moet zijn hoeveel werk het ontwikkelteam denkt nodig te hebben om de user story te realiseren.

Inschatten hoeveel tijd het kost om een bepaalde user story te implementeren is niet eenvoudig. De ervaring leert dat we bijna altijd te optimistisch schatten.

Om toch een betrouwbare inschatting te maken, heeft het ontwikkelteam veel details over de requirements nodig. Het team wil daarom precies weten wat voor software ze moet ontwikkelen. En zelfs dan blijft de kans groot dat ze tijdens de sprint met onvoorziene zaken en tegenvallers te maken krijgt.

Geen wonder dat veel ontwikkelaars huiverig zijn om commitment voor een sprint af te geven, zeker als ze daar op afgerekend worden.

In scrum is de term ‘commitment’ jaren geleden vervangen door ‘forecast’. In agile zijn schattingen voorspellingen, geen harde garanties. Als je het team er dan toch op afrekent, gaan ze zich (logischerwijs) indekken en willen ze vooraf gedetailleerde requirements hebben.

Relatieve schattingen

Uit onderzoek blijkt dat mensen niet goed in uren of andere absolute grootheden kunnen schatten.

Heb jij bijvoorbeeld enig idee hoeveel vierkante meter de oppervlakte van Duitsland is, of van Denemarken? Grote kans van niet. En als we je vragen hoeveel keer groter de oppervlakte van Duitsland is ten opzichte van die van Nederland? Kun je dan, zoals de meeste mensen, vrij snel een redelijke schatting geven?

Agile maakt gebruik van relatieve schattingen. Daarmee kun je met weinig informatie toch betrouwbaar schatten.

User stories worden daarom geschat in punten, story points. Bij relatieve schattingen bepaal je de omvang van de user stories ten opzichte van elkaar. Je vergelijkt een nieuwe user story met de bestaande stories. Bijvoorbeeld deze user story is ongeveer 2 keer zo groot of complex dan die andere user story.

Aanbevolen wordt om een aantal user stories als referentie te nemen en de overige stories daaraan te relateren. In projecten zien we te vaak dat een story point, in- of expliciet, voor een bepaald aantal uren werk staat. Dan ben je feitelijk toch in uren aan het schatten en mis je de voordelen van relatieve schattingen, en zijn dan dus minder betrouwbaar.

Nauwkeurige schattingen

Hoe kleiner een user story, hoe nauwkeuriger we hem kunnen schatten. Dit sluit mooi aan bij de agile werkwijze, waarbij alleen sprint ready (en dus kleine) user stories een nauwkeurige schatting vereisen.

De overige user stories en epics op de product backlog moeten nog opgesplitst en verder uitgewerkt worden. Dat doe je pas tegen de tijd dat ze door het ontwikkelteam opgepakt gaan worden.

Ook voor de schattingen geldt dat ze pas kort voor de sprint nauwkeurig hoeven te zijn. Voor de schattingen hanteren veel agile teams daarom de cijferreeks van Fibonacci.

Kenmerk van deze cijferreeks is dat de afstand tussen twee opeenvolgende cijfers steeds groter wordt (doordat de som van de twee voorgaande cijfers de waarde van het volgende cijfer bepaalt). Zo ziet de reeks van Fibonacci er uit: 1, 2, 3, 5, 8, 13, 21, etc.

Planningpoker, de bekendste agile techniek voor het inschatten van de product backlog, maakt gebruik van deze reeks van Fibonacci.

Voorspelbaarheid

Zoals gezegd biedt agile geen schijnzekerheid, maar wel voorspelbaarheid.

Daar zijn in de eerste plaats betrouwbare schattingen voor nodig. Die schattingen zijn niet, en kunnen niet, altijd nauwkeurig zijn. Maar door de iteratieve werkwijze en relatieve schattingen in story points (met behulp van de reeks van Fibonacci), is prima te voorspellen welke features binnen de deadline opgeleverd kunnen worden.

Ook zijn de consequenties van gewijzigde inzichten en extra requirements eenvoudig inzichtelijk te maken. Het voert te ver om hier uit te leggen hoe je dat doet. Daarvoor hebben we een heel artikel nodig.

Heb je interesse in die uitleg? Laat dat even aan ons weten via een reactie onder dit artikel. Dan wordt het onderwerp van ons volgende artikel ‘Zo maak je de consequenties van gewijzigde requirements op de overall planning inzichtelijk’.

Ook je ervaringen, vragen en opmerkingen naar aanleiding van dit artikel zijn meer dan welkom.


 

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Share This