Episode 20: Estimater

Vi trenger å snakke litt om estimater og estimering. Elsket og hatet. Begge deler av gode grunner. Finnes det egentlig gode grunner til å estimere arbeidsoppgaver? Og når bør man i så fall gjøre det?

Hei, Martin her, og du lytter til Fimbul!

Ideen om estimater er minst like gammel som jobben med å drive teknologiutvikling. Garantert enda eldre. Å estimere en oppgave er jobben med å sette en estimert tid for hvor lang tid det vil ta å utføre oppgaven. Jobber du med teknologiutvikling har du garantert vært involvert i estimering.

Hvordan man estimerer oppgaver og hvor ofte man gjør det, er helt avhengig av arbeidsprosessen og kulturen der man jobber.

Noen har estimering som en egen del av utviklingsprosessen, der de planlegger i detalj hvilke oppgaver som skal utføres og bruker mye tid på å forstå hvor lang tid hver oppgave vil ta. Er du kjent med vannfall som prosjektmetodikk, vil du kjenne igjen planleggingsfasen som omfattende og detaljorientert. Som oftest involverer slik estimering både utviklere, designere, forretningsutviklere, selgere, markedsførere og andre som blir involvert i oppgaven straks den påbegynnes.

Andre estimerer ikke i det hele tatt. Basert på magefølelse, eller erfaring som vi også kaller det, forstår man kanskje hvor omfattende en oppgave er bare ved å titte på den.

Begge disse er ytterpunkter, og selv tror jeg ingen av ytterpunktene er å foretrekke. Det er ytterpunkter sjelden, fordi man med ekstremiteter går glipp av verdifulle egenskaper ved alternativene.

La oss se på det ene ytterpunktet først. Detaljplanlegging.

Har man estimering som en egen del av utviklingsprosessen, hvor man samler mange mennesker, bruker man verdifull tid man heller kunne brukt på selve oppgaven. Samler du fire mennesker i et rom i en time har du brukt fire timer. To timer og du har brukt en arbeidsdag. Estimering er også vanskelig, og du kan sammenlikne det litt med værmeldingen. Jo lengre frem i tid jo mindre presis blir værmeldingen. Tilsvarende med arbeidsoppgaver. Jo større de blir jo vanskeligere blir de å estimere. Og jo vanskeligere de blir å estimere, jo mer tid føler man det er riktig å bruke på estimering. I hvert fall hvis du lever i dette ytterpunktet om at alt bør estimeres i detalj. Men uansett hvor grundig du gjør det, vil du oppleve at du gjennom selve arbeidet med oppgaven får ny kunnskap som gjør at det opprinnelige estimatet blir feil.

Så det andre ytterpunktet. Ingen estimering.

Jeg synes det er vanskelig å ikke estimere i det hele tatt. Det er produkteieren på teamet som har ansvaret for å holde backloggen oppdatert, altså å sikre at oppgaver er klare til utvikling til rett tid og i riktig rekkefølge. Når en produkteier i et team skal prioritere oppgaver, er det mange hensyn som må tas. Utviklerne har meldt inn behov for optimalisering av kode. Designerne har meldt inn behov for forbedring av brukeropplevelsen. Support har meldt inn en feil. Tre kunder trenger nye funksjoner. Sikkerhetsansvarlig har meldt inn behov for en sikkerhetsoppdatering. Så sitter produkteier der, da. Med alle oppgavene og skal flette dem sammen i en prioritert rekkefølge.

Det er i en slik prioritering mange hensyn å ta, og omfanget på den enkelte oppgave påvirker vurderingen. Hvis sikkerhetsoppdateringen fra sikkerhetsansvarlig vil ta tre uker å gjennomføre, mens de andre oppgavene kanskje tar en dag hver, blir sikkerhetsoppdateringen kanskje prioritert ned slik at man kan ta unna mange oppgaver som løser mange behov for mange involverte, før man iverksetter større oppgaver som vil sperre i lengre tid for påfølgende oppgaver. Du kan tenke på det som et puslespill som skal legges, der ingen av brikkene er i nærheten av å være like store. For å forstå hvordan puslespillet skal legges må man forstå størrelsen på og utformingen av brikkene.

For meg fremstår det som allerede nevnt ikke aktuelt verken å bruke overdrevent mye tid på estimering, eller å ikke estimere i det hele tatt. Dermed står vi igjen med at det finnes et behov for estimering. Spørsmålet blir derfor hvordan estimerer vi? Hvor ofte skal vi gjøre det? For hvilke oppgaver? Hvor lang tid skal vi bruke på estimering? Hvem skal involveres?

Det finnes etter min vurdering ikke gode og omforente svar på disse spørsmålene. Det er nok også et symptom på hvorfor estimering er omstridt. Noen misliker å bruke tid på estimering, fordi de selv ikke ser gevinsten av det, mens andre er avhengig av å forstå oppgavenes omfang i sin jobb. Jeg tror det koker ned til god kommunikasjon og respekt og forståelse for at vi har forskjellige behov avhengig av hva vi jobber med som et team.

Det kanskje viktigste man bygger inn i sin arbeidskultur er forståelse for andres behov. Er du den som ber om estimater må du forstå at du ber om hjelp til noe som kanskje ikke gir verdi til andre enn deg selv. Du ber om andre sin tid. På den andre siden er du som blir involvert i estimeringsarbeidet nødt til å forstå hvordan et estimat hjelper andre og til sist også deg selv. Det er med på å gjøre din egen arbeidshverdag enklere og som et team sitter man i den samme båten og vi skal samme sted. Som en på jobben hos meg så humoristisk påpeker når det er snakk om estimering: «Jeg liker å vite hva det vil koste når jeg setter bilen på service.» Tilsvarende kan vi tenke på jobben. Det er greit å vite hva det vil koste å gjennomføre et stykke arbeid.

Så er spørsmålet hvordan man gjør det i praksis. Selv har jeg aldri vært den som ber om at alle oppgaver skal estimeres. Noen oppgaver kan jeg titte på og forstå at dette er en relativt liten oppgave, ingen vits i å bruke tid på å mene noe om størrelsen. Andre oppgaver igjen fremstår for meg som uhåndgripelige. Tar det en dag? En uke? En måned? Jeg vil vite noe om omfanget, da det også sier noe om prisen for å få en oppgave gjort, og til sist også påvirker lønnsomheten i det som skal lages. Det hjelper ikke at tre kunder ønsker en funksjon, dersom det tar alt for lang tid å tjene inn igjen kostnaden med å lage den. For en vurdering av omfanget ber jeg gjerne om at noen gjør en kvalifisert vurdering for meg. Med kvalifisert mener jeg en som har kjenner domenet oppgaven tilhører og som kjenner løsningene vi arbeider med.

Når jeg i dag-til-dag-oppgaver ber om et estimat er det flere ting jeg kommuniserer tydelig.

Det første er at jeg ikke er ute etter et presist estimat. Et presist estimat vil aldri vise seg å være så presist, og man bruker som nevnt tid på å estimere. Når det er nevnt skal selvfølgelig den som estimerer få betenkningstid og lov til å gjøre egne vurderinger. Jeg pleier å spørre om denne oppgaven tar en dag, en uke eller en måned. Da kommer tankeprosessen fort i gang og jeg får gjerne svar som at «Åh, nei, ikke en måned. Vi er nok nærmere en uke, tenker jeg!» Flott, da har jeg det jeg trenger å vite.

Det andre jeg kommuniserer er at estimater aldri forplikter. På kontoret har jeg et bilde av Doctor Evil i ond latter med sine medsammensvorne, påført en tekst over hvor det står «We’ll ask for estimates and treat them like deadlines!». Et estimat er ikke en frist. Det er ikke noe jeg holder mot noen hvis det viser seg at estimatet var feil. Jeg er innforstått med at når jeg først ber om mindre presise estimater, så kan det være avvik. Jeg bruker det aldri i detaljplanlegging, først og fremst fordi jeg aldri detaljplanlegger. Samtidig er det den som estimerer sitt ansvar å ikke skjule kompleksitet og omfang. Hvis man oppriktig tenker at en oppgave tar en måned så sier man at man tror det tar en måned, og ikke si to uker fordi man håper det kan gå.

Det tredje som er viktig er at jeg aldri skal være misfornøyd med et estimat. Jeg sier på spøk at jeg krangler aldri med værmelderen bare fordi jeg ikke liker været som er meldt. En oppgave tar aldri mindre tid bare fordi jeg skulle ønske at den gjorde det, fordi jeg skulle ønske at vi kunne levert ny og verdifull funksjonalitet til kundene allerede i morgen.

Tidvis kommer det også større oppgaver eller konsepter, også kjent som epics, opp til vurdering. I smidig utvikling er et epic et konsept som igjen kan brytes ned i mindre oppgaver som kan rulles ut separat. For epics bruker jeg gjerne t-skjortemetoden, fra XS til XXL. På forhånd må du ha avgjort hvor mange dagsverk som inngår i de forskjellige størrelsene, og hva passer da bedre enn å bruke fibonacci-nummerserie, og fordeler dem fra 1 til 21 på størrelsesskalaen. Du finner en detaljert forklaring i notatene til episoden på fimbul.tech.

Men nå trenger jeg DIN hjelp! Jeg trenger hjelp til å dele erfaringene i Fimbul. Jeg trenger DIN hjelp til å dele Fimbul med minst én venn! Eller en kollega. Én venn hvor du tenker: «Dette tror jeg du vil ha nytte av!» Be dem om å besøke fimbul.tech.

Tusen takk for at du lytter til Fimbul, og for at du deler! Vi høres!