Jag har flera gånger stött på motstånd för användningen av Story Points vid estimering av backlog items. Story Points uppfattas som abstrakta och svåra att greppa.
“Varför använder vi inte helt enkelt timmar?” är en fråga som ofta dyker upp. Det är lätt att förledas att tro att estimering i timmar ger en bättre noggrannhet och tillförlitlighet. Jag vill peka på några exempel som visar på styrkan med Story Points och varför du bör använda dem istället.
För det första måste vi acceptera att estimering av ett arbete är per definition betingat med en viss osäkerhet. Det är just ett estimat vi ska leverera, ofta med en rad osäkra parametrar såsom; föränderliga krav, otydliga klarkriterier, olika möjliga tekniska lösningar, samt teknisk komplexitet. Visst skulle vi med möda, kunna klargöra dessa osäkerheter men ofta kostar det mer än det smakar. Vi vill leverera ett lagom gott estimat med minimal ansträngning.
Det har visat sig att kostnaden för att ge säkrare estimat växer exponentiellt. Ofta är det initiala, grova estimatet tillräckligt nära den verkliga storleken. Det förutsätter dock att en viss bearbetning av kraven har gjorts tidigare, så att man vet vad man estimerar. De gånger estimat felar gör de ofta det åt båda håll så att felen till viss del tar ut varandra.
Ett estimat skall ge oss en del av det beslutsunderlag som behövs för att kunna prioritera backloggen. Det behövs även för att lyckas planera in en lagom stor mängd arbete i varje sprint . Med estimatet kan vi även ta fram längre prognoser för vad som kan levereras om 6 månader eller ett år. I alla dessa fall kan vi acceptera en viss osäkerhet i estimatet.
Problematiken
Ett problem med användningen av timmar är den falska exaktheten man tror sig få. Det är lätt att räkna fram hur många mantimmar som ryms i sprinten och förledas att planera efter detta. Då är det lätt hänt att man tar på sig för mycket jobb. Om det saknas några timmar för att få med den där sista viktiga storyn kan man tänka sig att någon vill lösa detta genom att slänga in ytterligare en person i teamet för just denna sprint. I praktiken kommer det troligen falera kapitalt. Den nya personen är kanske inte insatt i domänen och har svårt att leverera fullt ut. Han eller hon kommer behöva mycket hjälp av sina kollegor, vilket leder till att även deras effektivitet minskar. Dessutom har gruppdynamiken rubbats vilket även det leder till minskad effektivitet för hela gruppen. I praktiken har väldigt lite vunnits av den nya resursen och ibland kan det istället varit en ren kostnad.
Dessutom är resultatet av en timmes jobb olika beroende på vem som utför arbetet. Estimaten är därför personberoende och blir förlegade när teamet förändras. Vid en sprintplanering blir det viktigare att veta exakt vem som ska utföra arbetet för att i realiteten veta om det kommer hinnas med eller inte. Detta är en detaljstyrning som varken är önskvärd eller effektiv och som med fördel undviks.
Story Points
När man estimerar m.h.a Story Points mäter man varje story relativt varandra. Detta innebär att det spelar ingen roll om en Story Point innebär en eller tio timmars jobb. Story A kommer alltid att vara dubbelt så stor som story B. Fördelen med denna relativitet är att det gör estimaten mer robusta och underlättar våra planeringar, både långsiktigt och kortsiktigt.
Fördelen för teamet
Estimeringarna kommer aldrig att bli förlegade, så länge kraven håller sig intakta. Dessutom kan inte produktägaren ifrågasätta teamets estimat på samma sätt som om man hade pratat om timmar. “Det där kan väl aldrig ta åtta timmar att göra?” skulle kunna myntas. Däremot är det svårt för någon att påstå “Det där kan väl aldrig ta 5 Story Points att göra?” utan att jämföra med andra krav.
Andra fördelar med användningen av Story Points är att det ger en enklare sprintplanering. Mängden jobb som kan planeras in beror då endast på teamets historiska velocitet. Komplexitet såsom ändringar i gruppsammansättning eller team med olika velocitet behöver då inte tas i beaktande. Historiskt vet vi mängden Story Points som brukar klaras av i en sprint. Har inget ändrat gruppens förutsättningar så är vår bästa gissning att kommande sprint bränner lika många poäng.
Även om gruppsammansättningen skulle förändras håller våra estimat fortfarande. Det är bara teamens velocitet som förändras och den kommer vi empiriskt ta reda på. Estimaten är inte längre personberoende.
Fördelen för Produktägaren
Långsiktigt tillhandahåller detta mer tillförlitliga prognoser som spänner över flera sprintar. Eftersom vi vet att estimaten endast förändras om kraven ändras, kan vi känna oss säkra på att dessa prognoser håller. Produktägaren kan då med god framförhållning kommunicera detta till kunden och ge dem trovärdiga löften eller förhoppningar avseende kommande releaser.
Om några nya krav behöver läggas till i backloggen är det enkelt att se vilka av de lägre prioriterade kraven som måste skäras bort för att få plats med det nytillkomna.
Vid förändring i teamens velocitet kan snabbt en ny prognos tas fram som speglar den nya situationen. Vi behöver inte sätta oss i nya estimeringsmöten för att gå igenom backloggen på nytt.
Sammanfattning
Story Points kan verka skrämmande och konstigt för den oinvigde. Men med lite eftertanke inser man att de förenklar vårt dagliga arbete och ger oss en rad fördelar. Inte bara för teamet, utan för hela organisationen.