Verhaal punten

Story points zijn een relatieve schattingseenheid die wordt gebruikt om aan te geven hoe groot een taak is in vergelijking met andere taken, in plaats van hoe lang het in uren of dagen zal duren. Een team kent punten toe door te vergelijken met referentietaken die ze al hebben voltooid. De verzamelde punten per iteratie vormen een basis voor het voorspellen hoeveel toekomstig werk er nog in de planning past.

De abstractie bestaat omdat mensen relatieve grootte betrouwbaarder inschatten dan absolute duur. Wanneer mensen gevraagd wordt hoe lang iets zal duren, baseren ze hun schattingen op optimistische aannames, laten ze onderbrekingen en herwerk buiten beschouwing en produceren ze consequent cijfers die naar beneden zijn bijgesteld. Wanneer ze gevraagd worden of het ene item groter is dan het andere, zijn dezelfde mensen aanzienlijk nauwkeuriger. Punten maken gebruik van die asymmetrie door vergelijkingen vast te leggen en de waargenomen doorvoer te gebruiken voor de omrekening naar tijd.

Punten zijn bedoeld om een ​​combinatie van volume, complexiteit en onzekerheid weer te geven, en niet alleen de benodigde inspanning. Een kleine wijziging in onbekende code met onduidelijke vereisten kan een grotere impact hebben dan een ingrijpende wijziging in een goed begrepen onderdeel. Teams die punten reduceren tot een maatstaf voor uren, verliezen deze dimensie uit het oog en reproduceren de schattingsproblemen die de techniek juist moest voorkomen.

De meetmethode is per definitie lokaal, een eigenschap die in de praktijk het vaakst wordt geschonden. Punten worden gekalibreerd aan de hand van de referentiepunten van een specifiek team en weerspiegelen de context, de codebase en de samenstelling van dat team. Het vergelijken van puntentotalen tussen teams is daarom zinloos, en het gebruik van velocity als productiviteitsmaatstaf voor teams leidt steevast tot een overschatting van de resultaten, omdat de prikkel bestaat om hetzelfde werk hoger te beoordelen.

Dezelfde vertekening treedt op binnen een team wanneer snelheid een doel wordt. Een team dat gevraagd wordt de snelheid te verhogen, kan dit direct doen door de schatting ruimer te maken, waardoor het cijfer verbetert terwijl er verder niets verandert. Omdat de meetwaarde gemakkelijk te manipuleren is en ontworpen is als hulpmiddel bij de planning in plaats van als prestatiemaatstaf, ondermijnt het gebruik ervan in prestatierapporten de bruikbaarheid voor het eigenlijke doel.

Schattingen brengen reële kosten met zich mee die nader onderzoek verdienen. Verfijnings- en planningssessies kosten veel teamtijd, en bij werk met een redelijk constante omvangsverdeling is het voordeel van voorspellingen ten opzichte van het simpelweg tellen van items gering. Teams die een aanpak zonder schattingen hanteren, tellen voltooide items en voorspellen op basis van historische doorvoer, wat vaak net zo nauwkeurig en aanzienlijk goedkoper is. Of schattingen hun kosten waard zijn, is een legitieme vraag en geen ketterij.

Herijking is nodig wanneer de referentiepunten niet langer representatief zijn, wat gebeurt naarmate een codebase volwassener wordt, de samenstelling van een team verandert of de aard van het werk verschuift. Teams die jarenlang dezelfde schaal blijven gebruiken, merken dat hun punten een context beschrijven die niet langer bestaat, en de daaruit voortvloeiende voorspellingen verschuiven zonder dat iemand de oorzaak kan achterhalen.

Waar punten nuttig blijven, is bij het aan het licht brengen van meningsverschillen tijdens het schatten. Wanneer teamleden zeer verschillende waarden toekennen aan hetzelfde item, blijkt uit de daaropvolgende discussie meestal dat ze de vereiste anders hebben begrepen, of dat één persoon zich bewust is van een complicatie waar de anderen niet aan denken. Dat gesprek is vaak waardevoller dan het uiteindelijke getal, wat een argument is om de discussie voort te zetten en pragmatisch te blijven bij de berekening.

Omdat de techniek alleen als planningshulpmiddel binnen één team functioneert, hangt de waarde ervan volledig af van hoe de omringende organisatie de resultaten gebruikt. In de praktijk wordt de schattingsmethode binnen één team vastgesteld. productontwikkelingEn wanneer meerdere teams aan één product werken, wordt de coördinatie beter beheerd door middel van afhankelijkheidsbeheer en het meten van de doorstroming. productafdeling dan door pogingen om schattingen tussen teams te normaliseren.