Introduktion

Den här artikeln har sin grund i att jag aldrig riktigt har varit tillfreds med estimering och hur vi har estimerat i de team som jag har varit en del av. Efter en Open X-diskussion på Agila Sverige 2014 om just estimering slog det mig vad det var som inte hade funkat för oss när vi hade estimerat. Så min tanke med artikeln är att dela med mig av dessa insikter.

Estimering

När jag pratar om estimering syftar jag på den aktivitet i exempelvis Scrum där vi försöker uppskatta hur stor arbetsinsatsen är för att uppfylla ett behov.

Min erfarenhet av estimering

Vi har oftast estimerat i samband med sprintplaneringen. Produktägaren har kommit med en mängd oestimerade user stories i någon slags viktighetsordning. Första storyn presenteras och hela gruppen visar ett kort från planning-poker-leken efter en liten stunds eftertanke. Om det var väldigt stor skillnad mellan deltagarna så följde en kort diskussion om varför det blev så. Sedan körs en ny runda med korten. Efter den brukar gruppen ha enats om en siffra. Och så fortsatte det tills högen med stories hade klarats av.

Detta sättet att göra sin estimering på är nog väldigt vanligt och står beskrivet i Mike Cohns bok om Agil estimering och planering. Det var också det verktyg vi fick lära oss när vi började använda Scrum som utvecklingsmetodik. Men jag har hela tiden känt att det saknas något i hur vi gjorde. Jag har till och med känt att hela konceptet estimering har varit mer eller mindre onödigt. Dess existensberättigande har jag dock motiverat med att vi i alla fall träffas och pratar lite om vilket jobb som ligger framför oss, vilket skapar en gemensam bild av backloggen i teamet. Men som sagt. Jag har hela tiden känt att de saknades något. Och jag har känt mig otillfredsställd med att våra estimat har varit så oprecisa. I ett av teamen samlade vi data för varje story. Förutom estimatet registrerade vi även datumet när vi började arbeta på den och datumet när den var klar. Utifrån datan kunde vi egentligen bara dra två slutsatser: att våra estimat per story nästan alltid var helt fel och att vi i snitt hann med 4,7 stories per sprint. Det vill säga, för oss hade det räckt med att räkna stories i stället för story-points.

Agila Sverige 2014

När jag var på senaste Agila Sverige deltog jag i en Open X-diskussion om estimering. Vi var säkert 30 personer som var sugna på att prata om detta, vilket egentligen var för många för att det skulle bli en konstruktiv diskussion där alla hade möjlighet att bidra. Men det gjorde också att jag kom till den insikt som jag gjorde eftersom jag mest satt och lyssnade och funderade på vad som sas i diskussionen.

Jag upplevde att det snabbt blev två grupperingar. Programmerare i ena ringhörnan och produktägare/projektledare i den andra. Programmerarna använde argument som:

• Varför ska vi lägga tid på att ge tidsuppskattningar på något som är helt okänt? När vi redan från början vet att det blir helt fel!
• Ger vi er en siffra så känner vi oss tvingade att uppfylla den!

Projektsidan å sin sida använde argument som:

• Vi vill bara ha en uppskattning av hur svårt ni tror det är att göra uppgiften, så att vi lättare kan bestämma om det är värt att göra den och när den borde göras. Ni är de som bäst kan bedöma hur svårt något är.
• Vi vill kunna göra långsiktiga prognoser, så att vi kan få en känsla av när vi är klara med projektet.

Och så här höll vi på ett bra tag. Utan att någon sida egentligen tog in vad den andra sidan sa och utan att vi försökte förstå den andra sidans åsikt.

Då slog det mig! Det var ju samma sak som saknades i denna diskussion som jag saknade i vår estimering! Ett gemensamt syfte med varför vi estimerar.

Insikterna

Det som slog mig där under diskussionen på Agila Sverige var att vi inte har förstått det grundläggande syftet med estimeringen. Och det är att vi genom en konstruktiv diskussion först och främst måste förstå behovet som vi ska uppfylla. Men även förstår varandras behov av att träffas och diskuterar vad behovet är och hur svårt det är att uppfylla behovet.

Följande saker borde vi fundera över när vi estimerar:

• Målet

Att målet med estimeringen inte är att få fram en så exakt siffra som möjligt. Utan att tillsammans förstå behovet och hur svårt det kommer bli att uppfylla och leverera det. På en väldigt hög nivå dock. Det vill säga, det är viktigare att förstå behovet ur användarens/beställarens synvinkel än att förstå exakt vilken relationsdatabas vi behöver för att uppfylla behovet. Därför är det viktigt att vi timeboxar vårt möte så att vi håller oss fokuserade och inte svävar i väg i en alltför detaljerad diskussion.

Vi behöver även alla ha samma mål med diskussionen.

• Viktigt att alla är med

Att vi behöver ha med alla i diskussionen. Användare, utvecklare, produktägare, kunden, säljare, projektledare... Det vill säga alla som kan bidra till att vi tillsammans förstår vad behovet är och hur svårt det är måste vara med. Jag har varit med i estimeringsmöten där bara utvecklarna har deltagit. Resultatet blev att vi estimerade vad vi trodde var behovet. Inte det verkliga behovet. Det gjorde att vi också lade ner en stor mängd tid på att utveckla saker som inte uppfyllde behoven.

• Hur lång tid tar det?

Är en väldigt farlig fråga och borde banlysas från estimeringsdiskussionen eftersom frågan i stort sett kräver ett exakt svar från den tillfrågade. Frågan vi borde ställa är: Hur svårt är det?

• Det är ingen debatt!

Det måste vara helt prestigelöst. Med andra ord, det är ingen debatt där vi ska försöka överbevisa varandra utan vi ska hela tiden fokusera på att förstå behovet och varandra. Och utifrån det avgöra hur svårt det verkar.

Siffror

Jag har egentligen inget emot att vi använder siffror. Men för mig personligen och kanske många med mig så är det svårt att tänka på siffror på något annat sätt än att det är något konkret och exakt. Till exempel hur många äpplen finns det i skålen? Vad kostar lunchen? Det måste vi ta med i beräkningen. Kanske är det möjligt om man pratar om hela tiotal så som 10, 20, 50, 70, 100 i stället. Då känns de mer ungefärliga. Men för mig skulle graderingen stor, mellan och liten fungera bättre. Siffran kan hjälp oss att göra långsiktiga prognoser men det kan storlek också göra. Vi kan exempelvi göra prognoser såsom: Under en månad brukar vi klara av fyra stora och två små uppgifter. Eller som i mitt exempel ovan räkna på antalet stories per sprint i stället.

Sammanfattning

Det som slog mig där den fjärde juni 2014 på Agila Sverige var att vi hade haft helt fel fokus på våra estimeringar. Vi var på tok för fokuserade på att ta fram en exakt siffra på varje story när vi istället borde koncentrera oss på att förstå vad behovet är och utifrån det avgöra hur svårt det kommer att bli att uppfylla behovet.