Story points — zijn relatieve eenheden voor het meten van taakcomplexiteit in agile ontwikkelmethodologieën. In tegenstelling tot uren houden story points niet alleen rekening met tijd, maar ook met complexiteit, risico's en onzekerheid van de taak. Volgens Scrum.org, 2023 missen teams die relatieve beoordeling in story points gebruiken 25% minder vaak sprintdeadlines dan teams die in uren beoordelen.
Belangrijkste punten
Story points — zijn een metriek voor taakcomplexiteit die wordt gebruikt in Scrum en andere Agile-methodologieën. Het team beoordeelt elke taak niet in uren, maar in relatieve eenheden: „deze taak is twee keer zo complex als de referentie”. Deze benadering neutraliseert het snelheidsverschil tussen verschillende ontwikkelaars en richt zich op complexiteit.
Het concept van story points ontstond begin jaren 2000 met de popularisering van Scrum. Een van de eersten die de methode beschreef was Ron Jeffries in het kader van Extreme Programming (XP). Het idee was om af te stappen van beoordeling in „mens-uren”, die altijd onnauwkeurig is, naar relatieve complexiteit die het team collectief bepaalt. Tegenwoordig zijn story points de industriestandaard voor Agile-teams.
Bij beoordeling in story points houdt het team rekening met drie factoren: werkomvang (hoeveelheid code, schermen, logica), complexiteit (technische uitdagingen, nieuwe technologieën) en onzekerheid (onduidelijke vereisten, risico's). Eén story point kan „eenvoudige taak zonder risico's” betekenen, en 8 — „complexe taak met hoge onzekerheid”.
De keuze van de story point schaal beïnvloedt de nauwkeurigheid van de beoordeling en het gemak van planning. De populairste schaal is de Fibonacci-reeks, maar er zijn ook alternatieven.
| Schaal | Waarden | Voordelen | Nadelen |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Natuurlijke toename van spreiding bij grote taken | Complex voor nieuwe teams |
| Lineair | 1, 2, 3, 4, 5 | Eenvoudig en begrijpelijk | Geen spreiding voor grote taken |
| Exponentieel | 1, 2, 4, 8, 16, 32 | Maximale spreiding bij grote taken | Grote taken moeilijk te onderscheiden |
| T-Shirt | S, M, L, XL | Snelle ruwe beoordeling | Onnauwkeurig, conversie nodig |
De Fibonacci-reeks is niet toevallig gekozen. Het verschil tussen 1 en 2 is minimaal (50%), maar tussen 13 en 21 — aanzienlijk (62%). Dit weerspiegelt de realiteit: kleine taken worden nauwkeuriger beoordeeld, grote — met meer spreiding. Wanneer een taak op 21 story points wordt beoordeeld, begrijpt het team: „we weten niet hoe lang het duurt, maar zeker meer dan 13”. De Fibonacci-schaal voorkomt valse nauwkeurigheid.
Om de schaal te laten werken, spreekt het team een referentie af: „taak X — 1 story point”. Meestal wordt als referentie een eenvoudige, goed bekende taak gekozen: „voeg een tekstveld toe aan het scherm” of „repareer een bug van het type typfout”. Alle andere taken worden ten opzichte van de referentie beoordeeld. Zonder referentie verliezen story points hun betekenis — iedereen begrijpt de eenheid anders.
Velocity (snelheid van het team) — het gemiddelde aantal story points dat een team in één sprint afrondt. Dit is de belangrijkste metriek voor het voorspellen van projectdeadlines.
Velocity wordt berekend op basis van voltooide taken: de story points van alle taken die het team heeft kunnen afronden (definition of done is voldaan) worden opgeteld. Onvoltooide taken worden niet meegenomen. Voor nauwkeurigheid wordt het gemiddelde van de laatste 3-5 sprints genomen. Als het team bijvoorbeeld 20, 22, 18 en 24 story points in de laatste 4 sprints heeft afgerond, is velocity = 21 sp.
Door velocity en de totale omvang van de backlog in story points te kennen, kan het aantal sprints tot de release worden voorspeld. Als er bijvoorbeeld 210 story points in de backlog zijn en velocity = 21, zijn er 10 sprints nodig. Dit is een ruwe voorspelling die tijdens het werk wordt verfijnd. Belangrijk: velocity is een gemiddelde, geen verplichting. Plan volgens de ondergrens (18 sp), niet het gemiddelde.
Velocity kan niet worden verhoogd door een bevel — het is een symptoom van de gezondheid van processen. Duurzame groei van velocity wordt bereikt door: vermindering van technische schuld, verbetering van code-review processen, vermindering van contextwisselingen, automatisering van testen en CI/CD. Belangrijk: velocity van verschillende teams kan niet worden vergeleken — elk team definieert story points op zijn eigen manier.
Story points en uren hebben verschillende doelen en de keuze ertussen hangt af van de context. Ervaren teams gebruiken beide benaderingen voor verschillende taken.
Story points zijn onmisbaar voor sprintplanning: ze zijn niet afhankelijk van wie de taak uitvoert. Een junior kan 2 sp per dag doen, een senior — 4 sp, maar de beoordeling van de taak blijft 2 sp voor beiden. Story points maken het mogelijk om teamproductiviteit te volgen zonder ontwikkelaars te vergelijken. Dit vermindert politieke druk en verbetert de teamsfeer.
Uren zijn nodig voor externe verplichtingen: contracten, begrotingen, rapporten voor de klant. De klant wil niet „8 story points” weten, maar „3 weken”. Voor conversie van story points naar uren wordt historical conversion rate gebruikt: het team weet dat 1 sp = ongeveer 4 uur werk. Conversie moet transparant zijn en gebaseerd op data, niet op aannames.
Veel teams gebruiken een gecombineerde aanpak: taken worden beoordeeld in story points voor sprintplanning, waarna de manager ze omzet in uren/dagen voor externe rapportage. Het is belangrijk om twee systemen niet in één proces te mengen: óf u beoordeelt in story points en leidt tijd af uit velocity, óf u beoordeelt direct in uren.
De implementatie van story points gaat vaak gepaard met fouten die de voordelen van relatieve beoordeling tenietdoen. Hier zijn de meest voorkomende.
De meest voorkomende fout — het team spreekt af: „1 sp = 4 uur”. In dit geval verliezen story points hun betekenis en veranderen ze in uren onder een andere naam. Story points moeten relatief zijn, niet gekoppeld aan tijd. Als taak A twee keer zo complex is als taak B, krijgt deze 2 sp, ongeacht hoeveel uur het duurt.
Wanneer een taak na uitvoering wordt beoordeeld — is dit geen beoordeling, maar een constatering. Story points moeten vóór aanvang van het werk worden toegekend, op het moment van maximale onzekerheid. Post-factum beoordeling vertekent de velocity en levert geen voordeel op voor planning. Bovendien creëert het een vals gevoel van nauwkeurigheid.
Velocity vergelijken van team A en team B — een zinloze oefening. Elk team definieert de referentie en schaal op zijn eigen manier. Voor het ene team is 1 sp een eenvoudige taak van een uur, voor het andere — een taak van een dag. Alleen de velocity van hetzelfde team in dynamiek kan worden vergeleken: stijgt of daalt deze.
Wanneer verschillende taken met dezelfde complexiteit verschillende story points krijgen, en complexere — minder, raakt de schaal verbroken. Het team moet de schaal regelmatig kalibreren: elke 3-6 sprints retrospectief controleren in hoeverre de beoordelingen overeenkwamen met de werkelijke complexiteit. Dit verbetert de consistentie van beoordelingen.
Veelgestelde vragen
Story points hebben geen vast equivalent in uren. Het is een relatieve eenheid: 1 sp = complexiteit van de referentietaak. Voor conversie naar uren gebruikt u de historical conversion rate van uw team: deel het gemiddelde aantal gewerkte uren in een sprint door de velocity. Meestal is 1 sp = 4-8 uur, maar dit is individueel voor elk team.
Ja, story points kunnen worden gebruikt in Kanban, maar met kanttekeningen. In Kanban zijn er geen vaste sprints, dus velocity wordt niet per sprint berekend, maar per week of maand. Kanban-teams gebruiken vaak in plaats van story points de Cycle Time — de doorlooptijd van een taak van begin tot eind. De keuze hangt af van de specificiteit van het team.
Als beoordelingen uiteenlopen (de een geeft 3 sp, de ander — 13), is dit een signaal dat de taak slecht wordt begrepen. Decompon eer de taak in kleinere delen. Bespreek de risico's en onzekerheden die verschillende ontwikkelaars zien. Als de taak groot is — beoordeel deze dan als Spike (onderzoek van 2-4 dagen) in plaats van story points.
De overstap duurt 3-6 sprints. Begin met het kiezen van een schaal (Fibonacci — safest choice) en het bepalen van een referentietaak. Houd 2-3 Planning Poker-sessies. Bereken na elke sprint de velocity. Converteer story points niet naar uren — laat het team wennen aan het nieuwe systeem. Na 3 sprints zult u zien hoeveel de planning is verbeterd.
Nee, de beoordeling verandert niet. Story points zijn een voorlopige beoordeling van complexiteit, gemaakt vóór aanvang van het werk. Na uitvoering van de taak blijft de beoordeling hetzelfde, zelfs als de werkelijke inspanning anders was. Het achteraf wijzigen van de beoordeling vertekent de statistieken en maakt voorspelling zinloos. Analyseer afwijkingen in de retrospectives, maar wijzig de beoordeling niet achteraf.
Samenvatting
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook