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

Story points meten de relatieve inspanning van een taak (de omvang, complexiteit en onzekerheid samengevat in één getal), niet het aantal uren dat eraan zal worden besteed. U bepaalt de omvang van een backlogitem aan de hand van een referentiestory 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 deze ene verandering blijft de schatting standhouden wanneer deze met de werkelijkheid wordt geconfronteerd.

Waarom inspanning meten, en niet tijd?

Een team dat in uren inschat, hanteert in feite twee schattingen: de schatting waar de senior ingenieur in gelooft, 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 beantwoorden van de vraag „is dit omvangrijker dan hetgeen we tijdens de vorige sprint hebben afgerond?”. Storypoints baseren zich op het tweede.

Met relatieve schatting 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 ‘verankeringsbias’ en de ‘senioriteitsbias’ vermeden die bij schattingen in uren vaak de kop opsteken. Het getal dat hieruit voortkomt, is geen tijdsduur, maar een positie op een gezamenlijke schaal.

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

• Een schatting is geen toezegging. Wanneer men spreekt van „uren”, worden belanghebbenden ertoe aangezet om „8 uur” als een belofte te beschouwen; punten zorgen ervoor dat de schatting een prognose blijft.
• Verschillende mensen hebben voor dezelfde taak verschillende hoeveelheden tijd nodig. 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.

Hoe het schatten van story points in zijn werk gaat

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

Als een item groter uitvalt 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, grofere eerste beoordeling schatten sommige teams de omvang van de gehele backlog in T-shirtmaten en zetten zij pas het werk op 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 hoge en lage 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, verwordt elk gesprek over schattingen tot 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 ‘hoeveel’ is de schaal bedoeld. Voor het ‘of het punten oplevert’ geldt een vuistregel: ken punten toe aan alles wat het team oplevert als onderdeel van zijn 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 afgebakende reikwijdte en een redelijke omvang; stem er dus op zoals op 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 dat „we nog niet weten 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 vastgesteld omdat de oorzaak onbekend is; een stemming over storypoints geeft dus alleen weer wat het team hoopt te ontdekken. Plaats deze taken in een onderzoekstraject met een vaste tijdslimiet: besteed een dag of twee aan het onderzoek en kom vervolgens terug met een concreet verhaal over wat u 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 zijn inbegrepen die het team uitvoert als onderdeel van „done”: geautomatiseerde tests, handmatige verificatie, toegankelijkheidscontroles en beveiligingsbeoordelingen. De story is pas voltooid wanneer deze voldoet aan de [definitie van ‘klaar’]./guides/agile-estimation-guide/definition-of-done/

Teams die zich uitsluitend richten op ontwikkelwerk en de 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 ontstaan door de samenwerking met hen: het voorbereiden van de build, het opstellen van het testplan en het beantwoorden van vragen. Dat deel 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 is dus alleen zinvol in vergelijking met een 2, een 3 of een 8. Wanneer een team voortdurend verhalen van 1 punt produceert, 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 afgedreven: 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 nog herinnert en herdefinieer het uitgangspunt. 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 dat er „nooit een 1“ voorkomt. 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.

Storypoints en de retrospectieve

Schattingen behoren tot de meest voorkomende onderwerpen die een team tijdens zijn sprint-retrospective bespreekt. 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 schattingen 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 schatting: één getal dat weergeeft hoe groot een werkonderdeel is (de inspanning, complexiteit en onzekerheid samen) in vergelijking met een referentieverhaal dat het team reeds 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 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 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 het, 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 scores 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 aan te geven blijft de velocity een betrouwbare indicatie 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 tijdgebonden onderzoekstraject 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 alles wat er gebeurt tussen het moment dat een feature in de sprint wordt opgenomen en het moment waarop deze klaar is voor uitgifte, inclusief het testen en de kwaliteitscontrole die het team uitvoert als onderdeel van zijn ‘definition of done’. Als er alleen punten worden toegekend aan ontwikkelingswerk, 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, indien gebruikt als streefcijfer, 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 vergelijking.

Aanbevolen lectuur

• Waarom story points de reeks van Fibonacci gebruiken: waarom de verschillen groter worden naarmate de getallen toenemen.
• Story points versus uren: de valkuil van de omrekening, en wat u moet doen als iemand een datum nodig heeft.
• Velocity: het verwerken van keerpunten in een prognose zonder deze te verstoren.
• Agile schattingstechnieken: welke methode wanneer te 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.