Geen inschattingen van de Sprint Backlog met Task Points

Toen ik in 2005 het boek Agile Estimating and Planning schreef, had ik me al vijf jaar beziggehouden met verschillende schattingsmethoden. Nadat ik met een aantal teams – vooral met de teams die direct voor mij werkten – experimenten had uitgevoerd, had ik het gevoel dat ik er genoeg over geleerd had om het boek te kunnen schrijven.

Maar er was nog heel wat dat ik niet wist (en dat geldt natuurlijk nu nog steeds!). Daarom ging ik op zoek naar teams die hun projecten anders inschatten en planden dan ik deed. Sommige van die teams gebruikten naast Story Points ook Task Points voor het inschatten van hun Product Backlog Items.

Dat vond ik interessant. Destijds was ik al een voorstander van Story Points – en inmiddels ben ik vanwege de voordelen van Story Points een nog grotere fan geworden. Ik kon echter gewoon niet begrijpen waarom een team Task Points zou gebruiken. Maar omdat ik zo'n grote fan van Story Points was, wilde ik simpelweg meer te weten komen over de teams die met Task Points werkten.

Ik kon een paar teams overhalen om me te laten meekijken, zodat ik op die manier meer erover kon leren.

Wat ik daarbij ontdekte, bevestigde mijn aanname dat teams hun Sprint Backlog Items niet met Task Points zouden moeten beoordelen.

Het belangrijkste voordeel van Story Points

Het belangrijkste voordeel van Story Points is dat mensen met de meest uiteenlopende vaardigheden, ervaringsniveaus en achtergronden samen een inschatting kunnen geven voor hun werk.

Laten we een niet helemaal serieus bedoeld voorbeeld nemen en ons voorstellen dat ik samen met een octopus zou willen inschatten hoeveel moeite het kost om mijn auto te wassen.

Een octopus heeft vier keer zoveel armen als ik. Dus zou de octopus mijn auto ook vier keer sneller moeten kunnen wassen dan ik. (Ik zei toch al dat dit geen heel serieus voorbeeld is. Maar wacht even af.)

De octopus zal echter ook elke andere auto vier keer sneller kunnen wassen dan ik. De octopus en ik kunnen het er dus misschien over eens worden dat mijn kleine tweezitter ongeveer vijf Story Points krijgt en een wat grotere auto tien punten krijgt.

Story Points maken het voor de octopus en mij dus mogelijk om samen tot een bepaald aantal punten te komen – ook al is de octopus zeker een stuk sneller dan ik.

Taakpunten

Bij de teams die ik observeerde, viel me op dat een Task Point bijna hetzelfde was als een Story Point. Alle teams waarmee ik sprak, wilden echter een kleinere eenheid gebruiken dan Story Points.

Een team dat bijvoorbeeld tien Story Points per Sprint haalt, zou ongeveer 80 Task Points per Sprint kunnen halen.

De teams wilden simpelweg een kleinere en fijnmazigere eenheid om hun voortgang beter te kunnen volgen. Het is vergelijkbaar met een snelheidsmeter in de auto die de snelheid in lichtjaren per uur zou weergeven. Op die manier zou ik maar moeilijk kunnen vaststellen of ik me aan de snelheidslimiet houd of niet.

Fijnmazigere eenheden gebruiken was voor veel teams een goed idee. Het is immers behoorlijk lastig om met Story Points de dagelijkse voortgang te meten van een team dat bijvoorbeeld zeven Story Points in twee weken haalt. In dat geval zijn Story Points gewoon een te grote eenheid om nuttig te zijn.

Hoe zit het met uren?

Er is echter al een fijnere eenheid waar elk teamlid sowieso al mee vertrouwd is: uren.

Toen ik de teams observeerde bij het inschatten met Task Points, viel me op dat dit geen voordeel biedt ten opzichte van het inschatten van Sprint Backlog Items in uren.

Er is een fundamenteel verschil tussen Product Backlog Items (meestal in de vorm van User Stories) en Sprint Backlog Tasks: Aan een Product Backlog Item werken doorgaans drie tot vijf mensen; misschien een of twee programmeurs, een tester en eventueel een designer, architect, analist of technisch schrijver etc. Aan een Task werkt normaal gesproken slechts één persoon.

Dat betekent dat niet alle teamleden samen een inschatting voor een Task hoeven te geven, zoals dat bij een Product Backlog Item het geval zou zijn. Iedereen in het team heeft weliswaar de mogelijkheid om een inschatting voor de Task te geven, maar alleen degene die uiteindelijk aan de Task werkt, kan de definitieve inschatting maken.

Als hoogstwaarschijnlijk slechts één bepaalde persoon aan een Task zal werken, neem je ook de inschatting van die persoon voor de taak. Als twee of drie personen aan een Task zullen werken, laat je ofwel alle drie samen een inschatting geven, of je neemt de inschatting van de persoon die het meest waarschijnlijk het werk zal uitvoeren.

Als het werk tijdens de Sprint aan een andere persoon wordt overgedragen, zullen de inschattingen in het ergste geval gewoon veranderen. Als een sneller teamlid het werk van een langzamere collega overneemt, wijzigt diegene de inschatting van acht naar vier punten – of andersom.

Waarom geen Task Points?

Task Points hebben dus geen voordelen ten opzichte van uren. Ze hebben echter wel nadelen ten opzichte van Story Points:
- Veel teamleden zijn er niet mee vertrouwd.
- Er zijn basiswaarden nodig om überhaupt schattingen te kunnen maken.
- Er is een risico dat de schattingen zich na verloop van tijd niet meer op de oorspronkelijke basiswaarden baseren.

Mijn tip voor het werken met Task Points

Ik sloot mijn uitstapje in de wereld van Task Points af, zonder dat men mij van hun waarde kon overtuigen. Ik blijf een voorstander van commitment-georiënteerde Sprint Planning, zoals we die kennen. Misschien is capaciteitsgeoriënteerde Sprint Planning een betere benaming daarvoor. Naar mijn mening heeft het aanzienlijke voordelen ten opzichte van velocity-georiënteerde Sprint Planning.

Bij de meeste teams werkt commitment- of capaciteitsgeoriënteerde Sprint Planning met uren het beste. Sommige teams volgen dit proces, maar laten de inschattingen weg en gebruiken die alleen in meetings om te bepalen wat ze in de Sprint kunnen opnemen.

Andere teams schatten de Sprint Backlog Items simpelweg helemaal niet in. Elk van deze benaderingen kan goed werken zodra een team er ervaring mee heeft opgedaan.

Ik ben blij dat ik dit project heb uitgevoerd om meer te weten te komen over Task Points en de teams die ze gebruiken.

Wanneer ik naar alternatieve methoden voor het inschatten kijk, ben ik altijd een beetje teleurgesteld als een nieuwe aanpak niet beter is dan een bestaande. Maar dat is helaas vrij vaak het geval.

En toch zullen we de continue verbeteringen vinden waar elke Agilist naar streeft, als we zoveel mogelijk verschillende opties bekijken.

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

Product Owner: Taken & Uitdagingen

=> Ontdek wat een Product Owner de hele dag zoal doet.

Wat is een Scrum Story?

=> Hier ontdek je de verschillen tussen User Stories, Epics en Themes.