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

Storypoints meten de relatieve inspanning van een werkonderdeel (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 schatting te maken van de duur. Juist door die ene verandering blijft de schatting standhouden wanneer deze wordt getoetst aan de werkelijkheid.

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 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 „hoelang gaat dit duren”, maar verrassend goed in het beoordelen of „dit groter is dan wat 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ënniteitsvertekening, die vaak gepaard gaan met schattingen in uren, omzeild. Het getal dat hieruit voortkomt, is geen tijdsduur, maar een positie op een gezamenlijke schaal.

Door de omvang in werkinspanning in plaats van in uren te bepalen, worden drie problemen vermeden die schattingen op basis van uren altijd met zich meebrengen:

• Een schatting is geen toezegging. Wanneer er sprake is 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 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 puntentelling 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 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 opsplitsen zodat het team het kan begrijpen en binnen één sprint kan afronden.

Voor een snellere, grovere eerste schatting bepalen 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. De gehele backlog in één keer inschatten? Begin dan met affiniteitsschatting en wijs de groepen aan het einde punten toe.

Tijdens een ronde planning poker legt iedereen tegelijkertijd zijn kaart op tafel, 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 allerbelangrijkste bron 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 verfijningsbijeenkomst 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 het toegezegde werk, zodat het velocity-signaal weergeeft waar de capaciteit daadwerkelijk naartoe gaat.

Fouten

Een bug met een bekende oorzaak en een duidelijke oplossing 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 op 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 aan de hand is”: onderzoek de gegevenscorruptie, zoek uit waarom p99 is verdubbeld, klanten blijven dit melden en wij kunnen het niet reproduceren. De omvang van de oplossing is nog niet vastgesteld omdat de oorzaak onbekend is; een stemming over story-points geeft dus alleen aan 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 „klaar” zijn inbegrepen: geautomatiseerde tests, handmatige verificatie, toegankelijkheidscontroles en beveiligingsbeoordelingen. De story is pas ‘done’ wanneer deze voldoet aan de definitie van ‘done’.

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 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 prestaties van 1 punt neerzet, 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’en (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 herinnert en leg het 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 is er niets aan te pas.

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 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 indeling van het werk verfijnt. 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 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 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 waardering 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 cijfer 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 meegeteld bij story points?

Ja. Punten geven de omvang aan van alles wat er gebeurt 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 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 afgedreven en is de schaal in het honderd gelopen, waardoor alles wordt gezien 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 streefdoel, 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 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 op welke punten 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 user stories.
• Gratis Planning Poker voor agile teams: bepaal samen en in realtime de omvang van uw backlog.