Story points in ontwikkeling — wat zijn het, beoordelingsschalen en toepassing

Auteur: IT Sectr Gepubliceerd: 2026-08-06 Leestijd: 8 min

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 — relatieve eenheden van taakcomplexiteit, niet gebonden aan tijd.
  • Belangrijkste schalen — Fibonacci (1, 2, 3, 5, 8, 13, 21) en lineair (1, 2, 3, 4, 5).
  • Velocity — het aantal story points dat een team in een sprint afrondt, gebruikt voor voorspelling.
  • Belangrijkste voordeel — story points zijn niet afhankelijk van een specifieke ontwikkelaar en weerspiegelen de complexiteit voor het team.
  • Belangrijkste regel — de referentietaak bepaalt de schaal: het team spreekt af wat 1 story point is.

Wat zijn story points?

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.

Oorsprong van de term

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.

Factoren die worden meegenomen in story points

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

Story point schalen: hoe te kiezen

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.

SchaalWaardenVoordelenNadelen
Fibonacci1, 2, 3, 5, 8, 13, 21Natuurlijke toename van spreiding bij grote takenComplex voor nieuwe teams
Lineair1, 2, 3, 4, 5Eenvoudig en begrijpelijkGeen spreiding voor grote taken
Exponentieel1, 2, 4, 8, 16, 32Maximale spreiding bij grote takenGrote taken moeilijk te onderscheiden
T-ShirtS, M, L, XLSnelle ruwe beoordelingOnnauwkeurig, conversie nodig

Waarom Fibonacci? Psychologie van de schaal

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.

Referentietaak — basis van de schaal

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 van het team en voorspelling

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.

Hoe wordt velocity berekend

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.

Voorspellen via velocity

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.

Hoe velocity te verhogen

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 vs uren: wat en wanneer te gebruiken

Story points en uren hebben verschillende doelen en de keuze ertussen hangt af van de context. Ervaren teams gebruiken beide benaderingen voor verschillende taken.

Wanneer story points beter werken

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.

Wanneer uren noodzakelijk zijn

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.

Gecombineerde aanpak

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.

Veelvoorkomende fouten bij het werken met story points

De implementatie van story points gaat vaak gepaard met fouten die de voordelen van relatieve beoordeling tenietdoen. Hier zijn de meest voorkomende.

Story points koppelen aan tijd

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.

Post-factum beoordeling

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 van verschillende teams vergelijken

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.

Inconsistente schaal

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

Hoeveel uur zit er in één story point?

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.

Kunnen story points worden gebruikt in Kanban?

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.

Wat te doen als het team het niet eens kan worden over de beoordeling?

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.

Hoe stop je met beoordelen in uren en stap je over op 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.

Verandert de beoordeling van een taak in story points na uitvoering?

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

  • Story points — relatieve eenheden van complexiteit, niet gebonden aan tijd, basis van Agile-beoordeling.
  • Belangrijkste schalen — Fibonacci (aanbevolen), lineair, exponentieel, T-Shirt sizing.
  • Velocity — aantal story points per sprint; belangrijkste metriek voor deadlinevoorspelling.
  • Story points vs uren — story points voor sprintplanning, uren voor externe verplichtingen.
  • Veelvoorkomende fouten — koppelen aan tijd, post-factum beoordeling, teams vergelijken, inconsistente schaal.
  • Referentietaak — basis van de schaal; zonder verliezen story points hun betekenis.
  • Belangrijkste voordeel — story points zijn niet afhankelijk van de uitvoerder en maken focus op teamproductiviteit mogelijk.

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.

Bespreek het project

Lees ook