Historiepoeng

Story points er en enhet for relativ estimering som brukes til å uttrykke hvor stort et arbeidsstykke er sammenlignet med andre deler, snarere enn hvor lang tid det vil ta i timer eller dager. Et team tildeler poeng ved sammenligning mot referanseelementer de allerede har fullført, og de akkumulerte poengene som leveres per iterasjon gir et grunnlag for å forutsi hvor mye fremtidig arbeid som vil få plass.

Abstraksjonen eksisterer fordi folk estimerer relativ størrelse mer pålitelig enn absolutt varighet. På spørsmål om hvor lang tid noe vil ta, forankrer estimatorer seg på optimistiske antagelser, utelater avbrudd og omarbeiding, og produserer tall som konsekvent er skjevt nedover. På spørsmål om ett element er større enn et annet, er de samme personene betydelig mer nøyaktige. Poeng utnytter denne asymmetrien ved å fange sammenligning og la observert gjennomstrømning sørge for konverteringen til tid.

Poeng er ment å gjenspeile en kombinasjon av volum, kompleksitet og usikkerhet snarere enn bare innsats. En liten endring i ukjent kode med uklare krav kan være større enn en omfattende endring i et godt forstått område. Team som reduserer poeng til en proxy for timer mister denne dimensjonen og reproduserer estimeringsproblemene teknikken ble utviklet for å unngå.

Målet er lokalt basert på konstruksjon, som er den egenskapen som oftest brytes i praksis. Poeng kalibreres mot et bestemt teams referanseelementer og gjenspeiler teamets kontekst, kodebase og sammensetning. Det er derfor meningsløst å sammenligne poengsummer mellom team, og å bruke hastighet som et produktivitetsmål på tvers av team produserer pålitelig estimatinflasjon, siden insentivet er å gi det samme arbeidet høyere poengsum.

Den samme forvrengningen oppstår i et team når hastighet blir et mål. Et team som blir bedt om å øke hastigheten kan gjøre det umiddelbart ved å estimere mer generøst, og tallet forbedres mens ingenting endres. Fordi metrikken er trivielt manipulerbar og ble utformet som et planleggingshjelpemiddel snarere enn et ytelsesmål, ødelegger bruken i ytelsesrapportering dens nytteverdi for det faktiske formålet.

Estimering har en reell kostnad som fortjener gransking. Forbedring og planleggingssesjoner tar betydelig tid fra teamet, og for arbeid med en rimelig konsistent størrelsesfordeling er prognosefordelen liten sammenlignet med å bare telle elementer. Team som praktiserer tilnærminger uten estimater teller fullførte elementer og prognostiserer fra historisk gjennomstrømning, som ofte er like nøyaktig og betydelig billigere. Hvorvidt estimering tjener inn kostnaden sin er et legitimt spørsmål snarere enn en vranglære.

Rekalibrering er nødvendig når referanseelementene slutter å være representative, noe som skjer når en kodebase modnes, når et teams sammensetning endres, eller når arbeidets art endres. Team som bærer en original skala fremover i årevis, oppdager at poengene deres beskriver en kontekst som ikke lenger eksisterer, og de resulterende prognosene driver uten at noen identifiserer årsaken.

Der poengene fortsatt er nyttige, er når man skal avdekke uenighet under estimering. Når teammedlemmer tildeler svært forskjellige verdier til samme element, avslører diskusjonen som følger vanligvis at de forsto kravet annerledes, eller at én person er klar over en komplikasjon mens de andre ikke er det. Den samtalen er ofte verdt mer enn det resulterende tallet, noe som er et argument for å fortsette diskusjonen og være pragmatisk om regnestykket.

Fordi teknikken kun fungerer som et planleggingshjelpemiddel innenfor ett team, avhenger verdien helt av hvordan den omkringliggende organisasjonen bruker resultatet. I praksis avgjøres estimeringspraksis innenfor produktutvikling, og der flere team jobber med ett produkt, håndteres koordineringen bedre gjennom avhengighetshåndtering og flytmåling på tvers av en produktavdeling enn gjennom forsøk på å normalisere estimatene mellom teamene.