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

Storypoints geven de relatieve inspanning van een werkonderdeel weer (de omvang, complexiteit en onzekerheid samengevat in één getal), 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 geschatte duur te geven. 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 deze 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 hetgeen we tijdens de vorige sprint hebben afgerond”. Storypoints baseren zich op het tweede.

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

Door de omvang in inspanning in plaats van in uren te bepalen, worden drie problemen vermeden die schattingen op basis van uren vaak teisteren:

• Een schatting is geen toezegging. Uren nodigen belanghebbenden uit om „8 uur” als een belofte te beschouwen; punten zorgen ervoor dat de schatting een prognose blijft.
• Verschillende mensen doen er verschillend lang over om dezelfde taak uit te voeren. Een punt geeft het werk weer, niet de persoon.
• De duur houdt geen rekening met risico’s. Een korte maar onzekere taak kan risicovoller zijn dan een lange, goed begrepen taak; daarom wordt die onzekerheid in de punten meegenomen.

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 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.

Als een item groter blijkt te zijn dan ongeveer een 13, is dat meestal een teken dat u het in stukken moet opdelen zodat het team het kan begrijpen en binnen één sprint kan afronden.

Voor een snellere, ruwere eerste doorloop beoordelen sommige teams de omvang van de gehele backlog in T-shirtmaten en zetten zij pas het werk voor de korte termijn om in punten zodra dit is verfijnd.

Tijdens een ronde planning poker onthult iedereen tegelijkertijd zijn kaart, zodat niemand zich laat beïnvloeden door de luidste of meest gezaghebbende stem. Wanneer de hoogste en laagste schattingen uiteenlopen, lichten die twee personen hun redenering toe, en dat gesprek – waarin de aannames en verborgen complexiteit achter het getal aan het licht komen – is doorgaans waardevoller dan het getal zelf. In de volledige uitleg over planning poker wordt de werkwijze beschreven.

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 aspect van de relatieve inspanning verloren.

Welk werk dient u aan te wijzen?

Tijdens elke verfijningsvergadering komen twee vragen naar voren: levert dit überhaupt punten op, en zo ja, hoeveel? Voor het antwoord op de vraag „hoeveel” is de schaal bedoeld. Voor de vraag „levert het punten op” geldt een vuistregel: ken punten toe 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. Werk aan bugs en werk aan 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 dit melden en wij kunnen het niet reproduceren. De omvang van de oplossing is niet vastgesteld omdat de oorzaak onbekend is; een storypoint-stemming geeft dus alleen weer wat het team hoopt te ontdekken. Plaats deze op een onderzoeksspoor 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 „done” zijn inbegrepen: geautomatiseerde tests, handmatige verificatie, toegankelijkheidscontroles en beveiligingsbeoordelingen. De story is pas voltooid wanneer deze voldoet aan de definitie van ‘voltooid’.

Teams die zich uitsluitend richten op ontwikkelwerk 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, brengt het verhaal nog steeds de kosten mee die aan de ontwikkelingszijde gepaard gaan met de samenwerking: het voorbereiden van de build, het opstellen van het testplan en 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; een 1 heeft dus alleen betekenis in vergelijking met een 2, een 3 of een 8. Wanneer een team voortdurend resultaten van 1 punt boekt, verdwijnt dat verschil: alles wat klein is, krijgt een 1, alles wat groter is, een 2 of een 3, en de schaal is 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 afgedwaald: 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 apart 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 configuratiejustering 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 de achterstand grotendeels uit 1’en bestaat. 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.

Storypoints en de retrospectieve

Schattingen behoren tot de meest voorkomende punten die een team tijdens zijn sprint-retrospective evalueert. Wanneer taken stelselmatig te laag of te hoog worden ingeschat, wanneer de velocity sterk schommelt of wanneer „voltooid” werk steeds opnieuw wordt geopend, is de retrospectieve het moment waarop het team zijn gezamenlijke inschatting van de omvang bijstelt en de manier waarop het werk wordt opgedeeld, aanscherpt. De nauwkeurigheid van de inschattingen verbetert door die feedbackloop, niet door vooraf extra uw best te doen.

Veelgestelde vragen

Wat zijn story points binnen agile?

Storypoints zijn een eenheid voor relatieve inschatting: één getal dat weergeeft hoe omvangrijk een werkonderdeel is (de combinatie van de benodigde inspanning, complexiteit en onzekerheid) 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.

Waarom zou men story points gebruiken in plaats van uren?

Mensen zijn slecht in het inschatten van absolute tijd, maar goed in het beoordelen of het ene groter is dan het andere, en story points maken gebruik van die kracht. Ze vermijden ook de valkuil om een schatting als een vaste toezegging te beschouwen, houden rekening met het feit dat dezelfde taak bij verschillende mensen verschillende hoeveelheden tijd in beslag neemt, en betrekken niet alleen de duur, maar ook de complexiteit en het risico mee. Na enkele sprints wordt de velocity van een team, uitgedrukt in punten, een betrouwbaardere prognose dan de som van de schattingen in uren.

Hoe schat u story points in?

De meeste teams maken gebruik van planning poker. Iemand licht een backlog-item toe, het team bespreekt dit, en iedereen kiest in stilte een waarde uit een gezamenlijke schaal, meestal een Fibonacci-achtige reeks (1, 2, 3, 5, 8, 13). Iedereen maakt zijn keuze tegelijkertijd bekend; wanneer de schattingen sterk uiteenlopen, lichten degenen met de hoogste en laagste schattingen hun redenering toe en stemt het team opnieuw totdat er overeenstemming is bereikt. De discussie die verborgen complexiteit aan het licht brengt, is vaak waardevoller dan het getal zelf.

Moeten bugs story points krijgen?

Ja, wanneer de bug een bekende oorzaak en een duidelijke oplossing heeft: dan is het een story zoals elke andere, en door deze te signaleren 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 geven de omvang aan van alle werkzaamheden tussen het moment dat een feature in de sprint wordt opgenomen en het moment waarop deze klaar is voor uitrol, inclusief het testen en de kwaliteitscontrole die het team uitvoert als onderdeel van zijn ‘definition of done’. Als u alleen ontwikkelingswerk in punten uitdrukt, loopt de sprint telkens uit, omdat kwaliteitscontrole het knelpunt is waarmee niemand rekening heeft gehouden.

Waarom dient u artikelen met slechts één punt te 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 ingestort, waardoor alles wordt geïnterpreteerd als ‘klein of groter’. Kalibreer opnieuw aan de hand van een recent referentieverhaal in plaats van de schaal te verkleinen.

Kunt u story points tussen teams vergelijken?

Nee. Een storypoint wordt afgestemd op het eigen gevoel van een team voor de relatieve omvang, dus een 5 van het ene team is niet hetzelfde als een 5 van een ander team. Het vergelijken van velocity of puntentotalen tussen teams is zinloos en, wanneer dit als streefdoel wordt gebruikt, zelfs schadelijk: het zet teams ertoe aan om schattingen op te blazen. Story points zijn een planningsinstrument voor de eigen prognoses van één enkel team, geen productiviteitsmaatstaf voor vergelijkingen.

Aanbevolen lectuur

• Waarom story points de Fibonacci-reeks gebruiken: waarom de verschillen groter worden naarmate de getallen toenemen.
• Story points versus uren: de valkuil van de omrekening, en wat u kunt doen als iemand een datum nodig heeft.
• Velocity: het verwerken van keerpunten in een prognose zonder deze te verstoren.
• Agile schattingstechnieken: welke methode u wanneer moet gebruiken, en hoe elke methode tekortschiet.
• Sprint-retrospective: waarbij teams hun schattingen bijstellen die steeds niet kloppen.
• Handleiding voor agile schattingen: het volledige overzicht, van planning poker tot het opsplitsen van stories.
• Gratis Planning Poker voor agile teams: bepaal samen en in realtime de omvang van uw backlog.