In de praktijk heb ik de afgelopen jaren gemerkt dat Product Owners (P.O.) die lat graag hoog leggen. Op zich is dat niet vreemd: zij zijn de koppeling met de business en willen hen graag tevreden stellen.
Ze lijken zich echter niet altijd bewust van de psychologische effecten van het hoog leggen van die lat. Dat is natuurlijk ook afhankelijk van het team. Als de teamleden elkaar door-en-door kennen en wanneer ze al meerdere malen een constante hoge velocity hebben laten zien, dan zullen zij het als een uitdaging zien. Van een team met verbeterpunten durven de teamleden niet altijd weerstand te bieden. Daarom bij deze een, naar mijn mening, waardevol advies: kijk naar het gemiddelde van de laatste drie sprints. De kans dat je het gewenste aantal punten dan haalt is groter, dan wanneer je de lat op de theoretisch haalbare hoogte legt. Daarbij: het team bepaalt hoe hoog de lat ligt, niet de P.O.. Elk Scrum-team zou autonoom moeten opereren en dit is daar een voorbeeld van; de P.O. mag beïnvloeden, maar niet bepalen.
Het risico van inschatten
Waarom deze inleiding over werkdruk? Zodra je inschattingen gaat maken, kun je daarmee de behaalde resultaten meten. Daarmee kun je de ontwikkelsnelheid van het team, de velocity genoemd, bepalen. Het is voor het team van groot belang om vooraf duidelijk naar de P.O. en de stakeholders te communiceren dat de velocity een verwachting is zoals bij een voetbalwedstrijd: je hebt van tevoren een aardig beeld van het aantal punten dat je kunt scoren, maar er zijn veel in- en externe factoren die de wedstrijd kunnen beïnvloeden.
Geef nooit, maar dan ook nooit de verwachting dat de velocity ‘waarschijnlijk’ toe zal nemen! Als je dit doet, dan schep je verwachtingen en maak je de velocity tot een doel op zich en daar is het nooit voor bedoeld. De belangrijkste vraag is:
Waarom zou je inschatten?
Het enige doel om tijd te besteden aan het maken van inschattingen, is om voorspelbaar te kunnen leveren. Dat betekent niet dat je veel tijd aan het maken van schattingen moet besteden. Misschien hoef je er zelfs helemaal geen tijd aan te besteden.
Niet inschatten, maar meten
De afgelopen tijd heb ik me hier meer in verdiept en heb ik mijn mening iets bijgesteld. Er is in onze branche een beweging gaande met de naam #NoEstimates, naar het gelijknamige boek. Deze heb ik nog niet gelezen, maar de theorie zoals ik deze gehoord heb is vrij simpel: maak de user stories zo klein mogelijk, in principe tot op het niveau van een taak. De conventie zegt dat één taak niet meer dan een dag in beslag zou mogen nemen. Aan het eind van de sprint tel je het aantal afgeronde user stories: dat is je velocity. Dit is, zoals ik het nu zie, de meest zuivere vorm om voortgang te meten. Daarbij worden twee Agile principes geraakt: Simplicity–the art of maximizing the amount of work not done–is essential, omdat er minder tijd wordt besteed aan het proces, en Working software is the primary measure of progress.
Bij het eerder genoemde project Kennr van Alliade heb ik ten behoeve van deze blog nagevraagd wat het aantal user stories per sprint was. De sprintlengte was twee weken. Het resultaat: 8 tot 12 user stories per sprint, een enkele uitzondering daargelaten. Ondanks dat de user stories niet zo klein mogelijk gemaakt waren, is dat toch vrij stabiel.
Het lijkt misschien ongemakkelijk om op basis van eenvoudige tellingen een verwachting te doen. Toch denk ik dat het betrouwbaarder is dan ingeschatte grotere user stories: meten is tenslotte weten. Daarbij kan de tijd die anders gebruikt zou worden voor het inschatten nu gebruikt worden voor ontwikkeling. Ik hoop de theorie snel in de praktijk te kunnen toepassen.
Wel inschatten
Als er toch voor ‘gewoon’ inschatten gekozen wordt, kies dan in elk geval voor het inschatten van complexiteit in story points en zeker niet in uren: mensen zijn slecht in urenschattingen. Allemaal. Ook die ene die beweert het wel te kunnen en sarcastisch wordt zodra je over story points begint.
Onder complexiteit wordt alles verstaan dat gedaan moet worden om één user story van inlezen tot en met oplevering te krijgen, dus ook test, re-work, re-test, documentatie, build en release. Het principe is eenvoudig: mensen kunnen vrij goed vergelijken. Als we dieren vergelijken en stellen dat een hamster de grootte van 1 punt heeft, dan is een cavia ongeveer 2 punten en een kip 3. Een kat zou 5 punten kunnen zijn. Een hond 8 punten, een ezel 13 punten en een paard 20 (of 21) punten. Zo werkt het ook met user stories: als je 1 of 2 user stories als referenties gebruikt, dan kun je de andere user stories daarmee vergelijken. Daarbij schatten alleen degenen mee die de user story daadwerkelijk gaan realiseren.
Bespaar tijd
Tijdens het inschatten is het niet ongebruikelijk dat het team in discussies terecht komt of dat blijkt dat de user story nog niet geheel uitgewerkt (‘ge-refined’) is. Een paar tips:
- User stories die nog niet uitgewerkt zijn, worden direct teruggegeven aan het refinement team (zie mijn eerdere blog over het refinement-proces).
- Een user story moet in circa 1 minuut uit te leggen zijn.
- Gebruik voor de toe te kennen punten de rij van Fibonacci (1,2,3,5,8,13, etc).
- Stel met elkaar een aantal ‘spelregels’ op om het inschattingsproces te versnellen, bijvoorbeeld:
– Bij 2 opeenvolgende groottes (bijv. 3 en 5) wordt de grootste gekozen.
– Bij 3 verschillende opeenvolgende groottes (bijv. 3, 5 en 8) wordt de middelste gekozen.
– In alle andere gevallen: degenen met de laagste en met de hoogste inschatting lichten in maximaal 1 minuut hun keuze toe. Daarna volgt herstemming. Als daar weer ver afwijkende waarden gekozen worden, wordt het gemiddelde gekozen en deze naar boven afgerond.
– Sorteer alle user stories op de backlog op grootte/complexiteit. Zo zie je beter welke user stories ongeveer even complex zouden moeten zijn.
Deze laatste vorm, ook wel fast estimation genoemd, is bij het eerder genoemde project van Alliade toegepast om enkele sprints vooruit te
plannen. Het resultaat was dat de schattingen over de gehele linie goed overeen kwamen met ook de toegepaste reguliere inschattingen; enkele uitzonderingen daar gelaten. Hiermee kun je dus wel degelijk inschattingen doen en hiermee tijd besparen.
Focus
Tot slot: moeten er uren ingeschat worden? In elk geval niet bij user stories, maar eventueel wel bij de onderliggende taken. Naar mijn mening hangt het verder af van wat er met die inschattingen gedaan wordt. Zoals gezegd: mensen zijn slecht in urenschattingen. Als iemand de schattingen gebruikt om de druk op te voeren, dan kun je er beter mee stoppen. Ze zijn bedoeld om een verwachting te geven voor de benodigde hoeveelheid netto ontwikkeltijd, zodat daarmee keuzes kunnen worden gemaakt. Een burn-down-chart kan daarbij helpen. Zelf vind ik het prettig om urenschattingen bij mijn taken in te vullen, omdat het mij helpt om focus te houden.
Resumerend
Als inschattingen misbruikt worden om de druk, al dan niet bewust, op te voeren, dan gaat dat ten koste van de motivatie en prestaties van het team. Overweeg of tijd moet worden besteed aan inschattingen, of dat eenvoudige tellingen van aantal user stories volstaan. Zo niet: spreek met elkaar een paar simpele regels af om de tijdsbesteding te beperken tot het hoogst noodzakelijke. Schat alleen uren in van taken en alleen als er niet op afgerekend wordt. Een team kan alleen scoren als het vertrouwd wordt en als de lat niet te hoog ligt. Laat het team niet met een achterstand starten!
