Wat zijn story points? Het inschatten van de inspanning, niet van de tijd

Storypoints geven de relatieve inspanning, complexiteit en onzekerheid van het werk weer — niet het aantal uren. Hoe u de omvang kunt bepalen ten opzichte van een referentiestory, en de vragen waar teams vaak over struikelen.

Story points geven de relatieve inspanning van een werkonderdeel weer — de omvang, complexiteit en onzekerheid samengevat in één getal — en niet het aantal uren dat het in beslag zal nemen. U bepaalt de omvang van een backlog-item aan de hand van een referentie-story die het team al heeft opgeleverd („dit is ongeveer twee keer zo groot als die“), in plaats van een schatting te maken van de duur. Juist door die ene verandering blijft de schatting standhouden wanneer deze wordt getoetst aan de realiteit.

Waarom de inspanning meten, en niet de tijd?

Een team dat in uren schat, hanteert in feite twee schattingen: de schatting waar de senior ingenieur op vertrouwt, en de schatting die de junior ingenieur opschrijft nadat hij het aantal naar boven heeft afgerond om een verantwoordelijke indruk te maken. Mensen zijn onbetrouwbaar als het gaat om de vraag „hoe lang gaat dit duren”, maar verrassend goed in het beoordelen of „dit omvangrijker is dan wat we tijdens de vorige sprint hebben afgerond”. Story points baseren zich op dat tweede aspect.

Met relatieve schatting kan het team het erover eens worden dat het ene item omvangrijker is dan het andere, zonder dat iemand zich hoeft vast te leggen op een aantal uren — waardoor de verankerings- en anciënniteitsvertekening worden vermeden die bij schattingen in uren vaak optreden. Het getal dat hieruit voortkomt, is geen tijdsduur; het is een positie op een gezamenlijke schaal.

De schaal, en waar de punten voor dienen

De meeste teams stemmen op een Fibonacci-achtige schaal — 1, 2, 3, 5, 8, 13 — tijdens een ronde planning poker. De verschillen worden met opzet groter: hoe omvangrijker het werk, hoe minder iemand er werkelijk van weet, dus de schaal doet niet langer alsof u een 9 van een 10 kunt onderscheiden. Tel de punten bij elkaar op die een team aan het einde van elke sprint behaalt en u krijgt de velocity — het resultaat dat de voorspellende inputpunten eigenlijk beogen te opleveren.

De belangrijkste oorzaak van mislukking is het team dat begint met het omrekenen van punten naar uren. Zodra die omrekeningstabel op de wiki wordt geplaatst, ontaardt elk gesprek over schattingen in een discussie over de duur en gaat het begrip ‘relatieve inspanning’ verloren.

Welk werk dient u aan te wijzen?

Tijdens elke verfijningsbijeenkomst komen twee vragen naar voren: levert dit überhaupt punten op, en zo ja, hoeveel dan? Voor het „hoeveel” is de schaal bedoeld. Voor het „of het punten oplevert” geldt een vuistregel: geef punten aan alles wat het team oplevert als onderdeel van het toegezegde werk, zodat het velocity-signaal weergeeft waar de capaciteit daadwerkelijk naartoe gaat.

Fouten

Een bug waarvan de oorzaak bekend is en waarvoor een duidelijke oplossing bestaat, is een story. Deze heeft acceptatiecriteria („het formulier accepteert geen negatieve hoeveelheden meer“), een duidelijk afgebakende reikwijdte en een redelijke omvang — stem er dus op zoals bij elke andere story. Het verhelpen van bugs en het ontwikkelen van nieuwe functies strijden om dezelfde capaciteit, en dat moet tot uiting komen in de velocity.

De uitzondering vormt de bug waarvan de aard is: „we weten nog niet wat er precies aan de hand is“ — de gegevenscorruptie onderzoeken, uitzoeken waarom p99 verdubbeld is, klanten blijven het melden en wij kunnen het niet reproduceren. De omvang van de oplossing is niet vast te stellen omdat de oorzaak onbekend is; een stemming over het aantal story points geeft dus alleen weer wat het team hoopt te ontdekken. Plaats deze zaken in een onderzoekstraject met een vast tijdsbestek: besteed een dag of twee aan het onderzoek en kom vervolgens terug met een concreet verhaal over wat u ook hebt gevonden.

Testen en kwaliteitsborging

Storypoints geven de omvang van het werk weer tussen het moment dat „de story in de sprint wordt opgenomen” en het moment dat „de story klaar is voor levering” — waarbij alle kwaliteitscontroles die het team uitvoert als onderdeel van „klaar” worden meegerekend: geautomatiseerde tests, handmatige verificatie, toegankelijkheidscontroles en beveiligingsbeoordelingen. De story is pas voltooid wanneer deze voldoet aan de definitie van ‘klaar’.

Teams die zich uitsluitend op ontwikkelwerk richten en kwaliteitscontrole (QA) daar apart aan toevoegen, nemen elke sprint te veel hooi op hun vork, omdat QA het knelpunt is waar niemand rekening mee heeft gehouden. Als een apart QA-team verantwoordelijk is voor het testen, blijven de kosten aan de ontwikkelingszijde voor de samenwerking met hen toch bij het verhaal horen — het voorbereiden van de build, het opstellen van het testplan, het beantwoorden van vragen. Dat gedeelte is niet gratis, dus blijft het in de schatting opgenomen.

Waarom u zelden een artikel met slechts één punt wilt

Punten zijn relatief, dus een 1 is alleen zinvol in vergelijking met een 2, een 3 of een 8. Wanneer een team voortdurend 1-puntsprestaties neerzet, verdwijnt dat verschil — alles wat klein is, krijgt een 1, alles wat groter is, een 2 of een 3, en is de schaal verworden tot een muntworp.

De oplossing ligt niet in het verbieden van „1’s“ — dat is de „cargo-cult“-versie van de regel. De oplossing is om te vragen waarom zoveel werk aan de onderkant van de schaal terechtkomt. Meestal is het referentieverhaal verschoven: het team is sneller geworden en de oorspronkelijke „1“ is nu kleiner dan alles wat zij opleveren, dus kies een recenter referentiepunt dat het team zich herinnert en leg de basis opnieuw vast. Soms splitst het team tijdens de verfijning de taken te veel op, waarbij elk acceptatiecriterium als een afzonderlijk verhaal wordt behandeld — „de tekst van de knop bijwerken“ is geen verhaal, maar een acceptatiecriterium van een groter verhaal. En soms is het werk daadwerkelijk klein (een onderhoudskwartier, een tekstwijziging die juridisch moet worden beoordeeld, een configuratieaanpassing die de productie raakt); in dat geval vervullen de punten hun functie en valt er niets te corrigeren.

Het signaal waarop u moet letten, is niet „nooit een 1”. Het is het feit dat 1’en het grootste deel van de achterstand uitmaken. Eén of twee per sprint is prima. Als om de andere story een 1 staat, betekent dit dat de kalibratievraag al te lang niet meer is gesteld.

Veelgestelde vragen

Wat zijn story points bij agile?

Storypoints zijn een eenheid voor relatieve inschatting: één getal dat weergeeft hoe omvangrijk een werkonderdeel is — de inspanning, complexiteit en onzekerheid samen — in vergelijking met een referentieverhaal dat het team al heeft opgeleverd. Ze zijn bewust geen maatstaf voor tijd. Het team beoordeelt de omvang van elk onderdeel ten opzichte van de andere onderdelen, en niet ten opzichte van de klok.

Moeten bugs story points krijgen?

Ja, wanneer de bug een bekende oorzaak en een duidelijke oplossing heeft, is het een taak zoals elke andere, en door deze aan te geven blijft de velocity een getrouw beeld geven van waar de capaciteit naartoe gaat. De uitzondering hierop is de verkennende bug waarvan u de omvang nog niet kunt inschatten; plaats die in een onderzoeksspoor met een vaste tijdslimiet en bepaal de omvang van de daadwerkelijke oplossing zodra u de oorzaak kent.

Worden testactiviteiten meegerekend in de story points?

Ja. Punten bepalen de omvang van alle werkzaamheden tussen het moment dat een feature in de sprint wordt opgenomen en het moment waarop deze klaar is voor levering, inclusief het testen en de kwaliteitscontrole die het team uitvoert als onderdeel van zijn „definition of done”. Als men alleen ontwikkelingswerk in punten uitdrukt, loopt de sprint telkens uit, omdat kwaliteitscontrole het knelpunt is waarmee niemand rekening heeft gehouden.

Waarom zou u artikelen met slechts één punt vermijden?

Een paar zijn prima. Maar als het grootste deel van de achterstand uit 1’s bestaat, is het referentieverhaal van het team afgedwaald en is de schaal in het honderd gelopen — alles wordt nu gezien als ‘klein of groter’. Kalibreer opnieuw aan de hand van een recent referentieverhaal in plaats van de schaal te verkleinen.

Aanbevolen lectuur