Estimering – Story Points eller ideala dagar?

Det finns två huvudspår när det gäller estimeringstekniker i agila projekt (eller egentligen antagligen alla projekt när jag tänker efter). Antingen estimerar man i en abstrakt enhet eller så estimerar man i en enhet kopplad till tid. Den vanligaste abstrakta enheten är nog story points men eftersom att det är en abstrakt kan det egentligen vara vad som helst. Jag har träffat team som estimerar i gummibjörnar! Enheter kopplade till verklig tid är istället timmar, dagar, halvdagar eller liknande och kan antingen vara ideala enheter eller verkliga enheter.  Med ideala enheter menas en tidsenhet som kan ägnas helt fokuserat åt en uppgift. Man har hela problemet och lösningen i huvudet och kan jobba utan störningar eller avbrott.

Jag föredrar oftast att jobba med abstrakta enheter och väljer story points om jag kan. Fördelen med att jobba med abstrakta enheter är att man, i ett estimat, separerar uppskattningen av tid från uppskattningen av omfattning. Viktigt är också att man estimerar uppgifter i relation till varandra. Så en story som uppskattas till fem story points är mer än dubbelt så omfattande än en story på två poäng. På så sätt kommer de estimat man gör alltid vara aktuella och inte bli sämre eller behöva uppdateras över tiden. Ta t ex en uppgift som i början av projektet estimeras till att ta två ideala dagar att utföra. Under projektets gång utförs liknande uppgifter som gör att nya erfarenheter kommer till projektgruppen. Det gör i sin tur att den uppgiften nu bara kommer att ta en dag att utföra. Då måste man, om man har estimat i en enhet som är kopplad till tid, även uppdatera det estimatet. Det behöver man inte göra om man estimerar i abstrakta enheter och estimerar uppgifter i relation till varandra. I exemplet ovan kommer uppgiften fortfarande att ha samma estimerade antal poäng och inte behöva uppdateras.

Ett viktigt begrepp när man estimerar i en abstrakt enhet är den hastighet som teamet har. Ett teams hastighet är lika med det totala antal enheter som teamet har levererat under en sprint. Om ett team åtar sig att leverera ett antal krav eller stories som är estimerade till 30 story points och lyckas med den leveransen så blir teamets hastighet 30. Om teamet istället lyckas leverera 25 story points som helt klara och den sista storyn på fem poäng blir nästa klar så blir teamets hastighet 25. Hastigheten använder man sedan för att veta hur mycket jobb man kan åta sig i nästa sprint. Eftersom att alla krav eller stories är estimerade i relation till varandra gör man ett antagande att man inte kommer att kunna leverera speciellt mycket mer i kommande sprint än i en tidigare. Istället för att bara se till den senaste sprinten när man sätter hastigheten kan man t ex räkna ut ett snitt av de tre senaste eller liknande. Man kan också göra anpassningar till antalet poäng man åtar sig beroende på tillgänglig tid. Det kan ju vara lämpligt att minska ner antalet poäng under en sprit som t ex innefattar jul eller påsk.

Inom Scrum är ett av de viktigaste dokumenten för att veta om man kommer att kunna leverera i tid en burn down-chart. En burn down är ett diagram som visar den samlade bilden av vilka uppgifter som är klara och vilka som är kvar. På x-axeln har man dagarna i sprinten och på y-axeln har man summeringen av värdet för estimaten för uppgifterna som ingår i sprinten. I en del projekt har jag valt att behålla story points som enda estimat för ett krav och inte estimera de enskilda uppgifterna och ibland väljer jag att bryta ner estimaten och att också estimera enskilda uppgifter. Då funkar det oftast bäst att man använder timmar som mått. När jag har estimerat uppgifter så rapporterar man också hur mycket tid som är kvar på varje uppgift medan när man behåller story points kan man bara rapportera den som helt klar. En story kan alltså i det läget inte vara halvt färdig.

Jag ser fördelar i bägge sätten att jobba. Om man jobbar med att bränna ner på story points på stories istället för på timmar på enskilda uppgifter finns potentialen att spara mycket tid och blir effektivare som team. Man kapar helt enkelt en hel del overhead. Det krävs dock att man har små stories och att man jobbar nära produktägaren för att uppnå detta.

Det skulle vara intressant att höra hur ni jobbar med estimering och uppföljning av agila projekt…

Mvh Björn Eriksen
Björn jobbar till vardags på Connecta som systemarkitekt.

Taggar:

• Agile
• Projekt
• Björn Eriksen