Om at Estimere – og Hvordan du Kommer til at Elske Det igennem den Værdi det Giver Dig

Estimering er noget rigtig mange prøver at komme nemt om; som i helst slet ikke gøre. Eller få andre til at gøre for sig. Men hvorfor? At estimere ER et effektivt redskab når det kommer til at skaffe overblik og indsigt, hvis det bliver gjort smart. Og ja, der er selvfølgelig mere end en måde – nogle kan så være smartere i præcis din kontekst.

Hvordan estimerer du?

Hvis du arbejder indenfor IT og har gjort det i mere end 5 år, er du formentlig enten en af dem der selv arbejder med at estimere (på andres foranledning), eller gør hvad du kan for at skubbe det med at estimere over på en andens bord. Sidste mulighed er at du tilhører den heldigvis voksende gruppe der har set styrken i at estimere relativt – og specielt, den værdi det bringer med sig.

Hvorfor skal lige netop JEG estimere

Det er der mange gode grunde til.

• Der er nogen der har bedt dig om det. Og de kender dem der udbetaler din løn, så det er nok i bund og grund en god idé
• Det kan være du er chef for nogen, og beder om estimater fra andre så du kan skabe overblikket. Der sker typisk det at du alligevel skal estimere ”det der ikke kom estimater for”, uanset hvad grunden til det måtte være.
• Du er en del af et agile team og udfører hyppigt relativ estimering på ganske kort tid, og anvender disse estimater til at prognosticere dette og kommende sprint udfald.
• Du er en del af et agile team, og estimerer overhovedet ikke! På trods at dette er du stadig i stand til at forudsige dette om kommende sprints udfald.

Hvad skal estimater bruges til

Helt generelt bruges estimater til at forudsige noget på kortere eller længere sigt. Men helt ærligt, hvornår har du sidst set en langsigtet prognose der rent faktisk ramte bulls eye? Det sker, bevares. Men mener du frekvensen af det matcher omkostningen af at estimere og alle de opdateringer af dem, der typisk også bruges ressourcer på? Også hvis du indregner alle ”forbi’erne”.

Hvordan kan vi gøre det anderledes

Når vi arbejder på den agile måde, bruger vi det at estimere ofte men med er ret lille tidsforbrug. En sprint planlægnings session for et 2-ugers sprint tager omkring to timer, og end ikke al den tid er brugt på at estimere. Typisk er der 6-12 elementer der skal estimeres, og hver estimering tager fra 2-5 minutter. Ikke mere, men faktisk ofte mindre. Men bliver det præcist? Nej, egentlig ikke. Men det er ikke et problem, da det kommer til at passe i gennemsnit (og er du virkelig nysgerrig på det, så er der noget tung matematik der kan bevise det).

Forskellen ligger i at bruge relativ estimering i stedet for absolut estimering, samt at angive værdien i en tidløs enhed, som fx Story Points, eller hvad du har lyst til at kalde det. Estimaterne er specifikke for det team der har udført dem, og kan bruges til dette teams fremskrivninger som fx hvor meget de kan levere af produktionsklart software på en sprint, når det bruges i kombination med den realiserede velocity (teamets hastighed i story points).

Hvad er fordelene ved relativ estimering

Det er simpelt, hurtigt, omkostningseffektivt (hvad mere kan du ønske) og løser opgaven med at forudsige rimelig godt. Desuden aktiverer det hele teamet med at estimere, og leder derfor til mere velunderbyggede estimater. Sidst men ikke mindst, så kobles det at estimere med kvalificerende og opklarende spørgsmål, således at mere detaljeret information overføres fra rekvirent til teamet. I praksis er det information der ikke blev skubbet fra rekvirenten men i stedet trukket af teamet.

Men lige inden du sender hele dit estimeringsteam på porten, så er de stadig klart at foretrække hvis du byder på en opgave!

Er der så nogen faldgruber ved at estimere relativt

’There ain’t no such thing as a free lunch’. [Ukendt]

Så ja, der er mere du skal vide. Men det er mindre og ganske rimelige ting, hvorefter du effektivt kan begynde at estimere relativt til fremskrivninger.

• Det team der skal levere arbejdet, skal udføre estimaterne. Dels fordi estimater ikke kan overføres fra team til team. Men vigtigere er at teamet for væsentlig information mens de estimerer.
• Det er teamet – og ideelt alle på teamet – der estimerer. Der er ingen chefer (eller kløgtige sælgere) der skal påvirke estimaterne. Og egentligt ganske fair, da det er teamet der skal comitte til at levere arbejdet og dermed den ønskede produktionsklare løsning.
• Adgang till information forud for, og mens teamet skal estimere, direkte fra kilden dvs. rekvirenten er helt centralt. Teamet skal hurtigt vurdere en opgave i forhold til andre, for at afslutte estimatet.
• Respektfuldt samarbejde mens der estimeres. Uanset hvad der kommer op mens der estimeres, er bragt op af en grund. Og her er det både elementer der øger estimatet og kendte genveje der sænker estimaterne der er relevante.
• Det at estimere relativt kan bruges operationelt, i visse sammenhænge også taktisk men taber pusten før vi kommer til det strategiske niveau. Eller rettere, det kræver væsentlig mere erfaring at få succes med det på dette niveau.

Hvordan kommer jeg i gang

Det er nemt! Metoden kan forklares på 2 minutter, og et team kan have lært det på en time. Så det er desværre ikke her du kan finde begrundelsen for at du ikke kan/vil begive dig ud i at estimere relativt. Og som altid, søg efter videoer på nettet eller inddrag en agile specialist for at komme nemt og sikkert I gang.

Så alt taget i betragtning, så synes jeg det er et effektivt redskab som jeg gerne anbefaler. Lave omkostninger ved implementering, lave operationelle omkostninger, og rimelig kraftig prediktiv styrke også sammenlignet med traditionel estimering.

 

Held og lykke med at komme i gang med relativ estimering!

Majken Vildrik Thougaard, Uafhængig Agile Specialist & Ejer af VILMA Consulting

PS: Ikke at estimere (Not to estimate, no-estimate) svarer i denne sammenhæng alligevel til at estimere. Men på den indirekte måde hvor alle opgaver i stedet skal være nogenlunde lige store, hvorefter det er tilstrækkeligt at tælle antallet af opgaver, for at kunne fremskrive. Dog kræver det et ret modent team at kunne få succes med i praksis.