Het management en de business willen graag zekerheid. Ze willen weten wanneer welke features opgeleverd worden en of dat allemaal lukt voor de deadline en binnen budget.
Zekerheid is in een complexe omgeving niet te geven! Dat kunnen agile aanpakken 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 nodig van de omvang van de user stories. Dat is noodzakelijk om:
- De sprints voorspelbaar te maken, zodat het agile team 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
Een product backlog is een geprioriteerde lijst 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 team 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, hebben de ontwikkelaars veel details over de requirements nodig. Het team wil namelijk 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 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 (of Denemarken) 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 veel organisaties zien we dat een story point (im- of expliciet) voor een bepaald aantal uren werk staat. Dan ben je feitelijk toch in uren aan het schatten. Je mist dan de voordelen van relatief schatten, waardoor ze dus minder betrouwbaar zijn.
Nauwkeurige schattingen
Hoe kleiner een user story, hoe nauwkeuriger we hem kunnen schatten. Dit sluit mooi aan bij de agile werkwijze. Want alleen sprint ready (en dus kleine) user stories vereisen een nauwkeurige schatting.
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 agile team opgepakt 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 impact van wijzigingen zichtbaar’.
Ook je ervaringen, vragen en opmerkingen naar aanleiding van dit artikel zijn meer dan welkom.
Nicole de Swart & Priya Soekhai
Helder artikel! Ook al ken ik de inhoud al, het wordt in duidelijke taal uitgelegd. Kan ik zo aan nieuwelingen in de materie voorleggen!
Ik ben geinteresseerd in consequenties van gewijzigde inzichten en extra requirements eenvoudig inzichtelijk te maken.
Dus gaarne lees ik dit in een volgend artikel
De problematiek ken ik ondertussen. De oplossing niet 🙂
Ik ben dus heel geïnteresseerd in de uitwerking in een volgend artikel.
Overigens zie ik als ik het goed zie in het artikel kort 3 stromingen langs elkaar gelegd. Traditioneel, agile en scrum. De focus gaat uiteindelijk naar agile maar hoe verhoud zich dat binnen scrum ? Of haal ik hier, net als veel management, termen door elkaar ?
Met dank voor jullie mooie artikelen.
Hallo Frans, Leuk te horen dat je onze artikelen waardeert.
Het artikel gaat inderdaad over agile en we hebben even het verschil met traditionele planningen aangehaald. Een nadere verbijzondering naar scrum hebben we niet zo bedoeld. Relatieve schattingen worden bijvoorbeeld agile breed gehanteerd en veel begrippen die van oorsprong uit scrum komen ook. Vandaar misschien de suggestie.
Heldere uiteenzetting en goed uit te leggen aan anderen. Het is nog wel een uitdaging om traditioneel denkende business stakeholders mee te krijgen in de denkwijze van “voorspellen” in plaats van afspraak=afspraak. In plaats van “voorspelling” gebruik ik trouwens liever de term “verwachting” (net zoals het KNMI een weersverwachting afgeeft en geen voorspelling).
Ik ben zeker geïnteresseert in hoe je voortschrijdend inzicht verwerkt in je verwachting. En waar ik ook in geïnteresseerd ben is het onderscheid tussen de korte-termijnverwachting (de voldoende uitgesplitste kop van het product backlog) en de lange termijn (hele product backlog inclusief de nog uit te splitsen user stories). Ik kan me voorstellen dat dat iets is met een toenemende bandbreedte, aangezien de spreiding van de kans op juiste inschatting van de story points een stuk groter zal zijn bij deze items.
Dag Gerco, fijn om te horen dat je het artikel duidelijk vindt. Ik ben het eens met wat je schrijft dat het een uitdaging blijft om traditioneel denkend management en business stakeholders mee te krijgen in de denkwijze van reëele verwachtingen en passende ambitie in plaats van keiharde deadlines. Agile is in de 1e plaats een kwestie van flexibiliteit en de juiste mindset. Bij voldoende interesse zullen we in het volgende artikel zeker ingaan op voortschrijdend inzicht en de consequenties van gewijzigde inzichten voor de korte en lange termijn.
Zeker heb ik interesse in de uitleg hoe je de consequenties van gewijzigde inzichten kan tonen.