Het Probleem met Story Points: Betere Alternatieven voor Engineering Teams

Story points zijn de de facto standaard geworden voor het schatten van werk in agile ontwikkeling. Loop een planning meeting van een engineering team binnen, en je hoort waarschijnlijk discussies over of een taak een 3 of een 5 is, of waarom die "eenvoudige" feature op de een of andere manier een 8 werd.

Maar hier is de ongemakkelijke waarheid: story points creëren vaak meer problemen dan ze oplossen. Na jaren van teams te zien worstelen met schatting, is het tijd om betere alternatieven te verkennen die engineering teams daadwerkelijk helpen waarde te leveren.

Waarom Story Points Tekortschieten

De Illusie van Precisie

Story points beloven relatieve schatting zonder de druk van tijd-gebaseerde verplichtingen. In theorie zou een 5-punten story ongeveer 2,5 keer langer moeten duren dan een 2-punten story. In de praktijk houdt deze relatie zelden stand.

Overweeg dit scenario: Je team schat een gebruikersauthenticatie feature op 5 punten. Later schat je een betalingsintegratie op 5 punten. Zijn deze echt equivalent in complexiteit? De authenticatie zou eenvoudige CRUD operaties kunnen inhouden, terwijl de betalingsintegratie third-party API integratie, security compliance en error handling vereist.

Gaming en Velocity Theater

Zodra story points een metric worden die ertoe doet, manipuleren teams onvermijdelijk het systeem. Ontwikkelaars blazen schattingen op om velocity er beter uit te laten zien. Managers zetten teams onder druk om velocity te verhogen zonder te begrijpen dat story points relatief zijn, niet absoluut.

Dit creëert "velocity theater" – de illusie van voortgangsmeting terwijl werkelijke productiviteitsinzichten worden verduisterd. Een team dat 50 punten deze sprint voltooit versus 40 punten vorige sprint is niet noodzakelijk verbeterd; ze hebben mogelijk gewoon hun schattingen geherkalibreerd.

Het Planning Poker Probleem

Planning poker sessies, hoewel boeiend, worden vaak oefeningen in valse consensus. De luidste stem wint, of teams convergeren naar schattingen om conflict te vermijden in plaats van complexiteit echt te beoordelen.

Erger nog, deze sessies verbruiken aanzienlijke tijd. Een typische planning sessie zou 30 minuten kunnen besteden aan het debatteren of een feature 3 of 5 punten is – tijd die besteed zou kunnen worden aan werkelijke probleemoplossing of het opdelen van werk in kleinere, beheersbare stukken.

Betere Alternatieven voor Story Points

1. T-Shirt Sizing met Duidelijke Definities

In plaats van numerieke story points, gebruik t-shirt maten (XS, S, M, L, XL) met expliciete, team-specifieke definities:

• XS: Eenvoudige bug fix of config wijziging (< 1 dag)
• S: Goed begrepen feature met duidelijke requirements (1-2 dagen)
• M: Feature die wat onderzoek of coördinatie vereist (3-5 dagen)
• L: Complexe feature die meerdere systemen beslaat (1-2 weken)
• XL: Epic die opdeling in kleinere stukken vereist

Deze aanpak behoudt de voordelen van relatieve sizing terwijl valse precisie wordt vermeden. Teams begrijpen natuurlijk dat een XL item opgedeeld moet worden, wat het "8-punten story die drie sprints duurt" probleem voorkomt.

2. Cycle Time en Lead Time Metrics

Richt je op het meten van werkelijke leveringstijden in plaats van geschatte complexiteit:

Deze metrics bieden concrete data over je leveringsproces zonder de subjectiviteit van schatting. Ze belichten echte knelpunten: trage code reviews, langdurige QA cycli of deployment wrijving.

3. Throughput-Gebaseerde Planning

In plaats van individuele items te schatten, track hoeveel items je team per tijdsperiode voltooit. Deze aanpak richt zich op flow in plaats van schattingsnauwkeurigheid.

Bijvoorbeeld, als je team typisch 8-12 kleine items of 2-3 grote items per sprint voltooit, plan dienovereenkomstig. Deze methode erkent dat schatting inherent onzeker is terwijl nog steeds voorspelbare planning mogelijk is.

4. Monte Carlo Forecasting

Gebruik historische data om probabilistische voorspellingen te maken. Als je team vergelijkbare features in 3-8 dagen heeft voltooid in de afgelopen zes maanden, kun je voorspellen met betrouwbaarheidsintervallen:

• 50% kans op voltooiing binnen 5 dagen
• 80% kans op voltooiing binnen 7 dagen
• 95% kans op voltooiing binnen 10 dagen

Deze aanpak omarmt onzekerheid in plaats van het te verbergen achter valse precisie.

Verandering Implementeren: Een Praktische Aanpak

Begin met Kleine Experimenten

Verlaat story points niet van de ene op de andere dag. Voer in plaats daarvan parallelle experimenten uit:

1. Week 1-2: Ga door met story point schatting maar track ook werkelijke cycle times
2. Week 3-4: Probeer t-shirt sizing voor nieuw werk terwijl je leveringspatronen monitort
3. Week 5-6: Experimenteer met throughput-gebaseerde planning voor één team of project

Vergelijk de nauwkeurigheid en bruikbaarheid van elke aanpak voor je specifieke context.

Focus op Continue Verbetering

Ongeacht je schattingsmethode, het doel zou continue verbetering in leveringscapaciteit moeten zijn. Regelmatige retrospectives zouden zich moeten richten op:

• Wat vertraagde ons deze iteratie?
• Hoe kunnen we cycle time verminderen?
• Wat zou ons helpen consistenter te leveren?

Meet Wat Ertoe Doet

In plaats van velocity, track metrics die direct correleren met business waarde:

• Deployment frequentie: Hoe vaak je naar productie shipped
• Lead time voor wijzigingen: Tijd van commit tot productie
• Gemiddelde tijd tot herstel: Hoe snel je problemen oplost
• Wijziging failure rate: Percentage deployments die problemen veroorzaken

Deze DORA metrics bieden actionable inzichten in engineering effectiviteit zonder de overhead van story point schatting.

Wanneer Story Points Nog Steeds Zinvol Kunnen Zijn

Story points zijn niet universeel slecht. Ze kunnen goed werken voor:

• Nieuwe teams die leren werk samen op te delen
• Zeer onzekere domeinen waar relatieve vergelijking helpt
• Cross-team coördinatie wanneer je een gemeenschappelijke schattingstaal nodig hebt
• Stakeholder communicatie wanneer business partners het concept begrijpen

De sleutel is ze te gebruiken als tool voor conversatie en planning, niet als een precies meetsysteem.

Conclusie

Story points beloofden het schattingsprobleem op te lossen, maar ze creëren vaak nieuwe problemen: valse precisie, gaming en tijdrovende planningsrituelen. De alternatieven – t-shirt sizing, cycle time metrics, throughput planning en probabilistische forecasting – bieden meer praktische benaderingen voor het plannen en meten van engineering werk.

Het beste schattingssysteem is degene die je team werkelijk nuttig vindt voor het nemen van beslissingen en het verbeteren van levering. Focus op continue verbetering, meet wat ertoe doet, en onthoud dat het doel geen perfecte schatting is – het is het efficiënt en voorspelbaar leveren van waarde aan klanten.

Begin klein, experimenteer met verschillende benaderingen, en kies de methoden die je team helpen betere software sneller te shippen. Je toekomstige zelf (en je team) zal je dankbaar zijn voor het voorbijgaan van de story point val.