− Nei, erfaring gjør deg ikke flinkere til å estimere

Teamet setter seg ned i starten av sprinten og snakker seg igjennom hvor lang tid hver oppgave tar. Noen ganger skyter de for høyt, noen ganger for lavt. I en sprint kom de ikke gjennom oppgavene i det hele tatt, i neste sprint plukker de flere fra køa eller småflikker på brukergrensesnittet.

Men når teamet har jobbet sammen en stund på samme produkt, blir estimatene mer presise. Det er gjengs oppfatning.

Men det stemmer ikke, skal vi tro fersk forskning.

− Det finnes ingen empiriske bevis for at estimatene blir mer nøyaktige over tid.

Det skriver professor i informatikk, Lan Cao, ved Old Dominion University i Norfolk i USA i en artikkel publisert i august.

Hun har gått igjennom og sammenlignet estimater på oppgavenivå med faktisk brukt tid på utvikling i et stort smidig prosjekt, gjennom 46 iterasjoner på 21 måneder. Det blir det volum av: 7000 estimater med tilhørende tall for faktisk tidsbruk er tatt med i undersøkelsen.

I tillegg har Cao intervjuet utviklere i prosjektet.

Ingen forbedring

Å kunne estimere hvor lang tid en oppgave tar er helt sentralt for å lykkes med smidig utvikling, og trekkes ofte frem som en utfordring i starten av større prosjekter.

Estimering er ikke bare viktig for å kunne fordele oppgaver fra dag til dag, det kan være avgjørende for prosjektets fremdrift og for prioriteringen mellom oppgaver. Overestimering, at teamet tror oppgaven tar lengre tid enn den faktisk gjør, kan gjøre teamet mindre effektivt, underestimering, at teamet tror oppgaven tar kortere tid, kan føre til forsinkelser og misnøye.

Derfor gjøres det stadig forsøk på å forbedre treffsikkerheten, med maskinlæring, planning poker, å trekke inn erfarne utviklere og ikke minst, tilbakemeldingslooper. Grunntanken i smidig utvikling er nettopp at strukturert læring i en tilbakemeldingsloop i hver sprint, skal gjøre teamet mer og mer effektivt, også når det gjelder estimerings-jobben.

Det har imidlertid vært forsket lite på den faktiske effekten av erfaring, mener Cao.

Og den er ifølge tallene lite oppløftende. Verken Caos eller tidligere undersøkelser har klart å finne noen empiriske bevis for at estimatene treffer bedre når teamet har gjort øvelsen flere ganger.

Problemet er at læringen er basert på «gårdagens vær», som sier lite om hvordan været blir i neste uke, mener forskeren.

Likevel mer selvsikre

Til tross for at estimatene ikke blir bedre, blir utviklerne mer selvsikre.

− Erfaring er den viktigste faktoren, gjennom prosjektet har vi fått mer erfaring med smidig og blitt godt kjent med kodebasen, så har estimatene etter hvert blitt veldig nøyaktig, sa en utvikler i prosjektet til forskeren.

− Det tok mange iterasjoner å bli god på estimering, sa en annen.

Selv om dataene viste at det ikke var noen endring i hvor godt estimatene traff, viste altså intervjuene at utviklerne fikk større og større tiltro til egne estimater, skriver Cao.

Ikke vanskeligere å estimere feil enn ny funksjonalitet

Hun undersøkte også om det er forskjell i treffsikkerhet mellom estimater av feil og av ny funksjonalitet.

Det var det ikke.

Å estimere feilrettinger er sett på som vanskeligere enn å estimere ny funksjonalitet, fordi oppgaven gjerne innebærer feilsøking, en aktivitet det er notorisk vanskelig å anslå når blir ferdig.

− Dataene tilsier at det ikke er noen forskjell på hvor store feilmarginer det er mellom feilretting og refaktoreringsoppgaver og ny funksjonalitet, skriver Cao.

I intervjuene forskeren gjennomførte, ga likevel utviklerne uttrykk for at de oftere traff på estimater om ny funksjonalitet enn feilretting.

Lettere å overestimere

I tallene Cao har undersøkt, er fordelingen på over- og underestimering av oppgaver på ny funksjonalitet omtrent fifty-fifty.

Tidligere forskning har vist at utviklingsoppgaver har en tendens til å bli overestimert oftere enn de blir underestimert.

− En av grunnene kan være Parkinsons lov, skriver Cao.

Parkinsons lov sier at oppgaven utvides til tiden som er tilgjengelig for å fullføre den.

Har teamet estimert at oppgaven tar tre dager, og den tar to, bruker de den siste dagen på å flikke videre, istedenfor å plukke en annen oppgave.

En annen grunn kan være at det er lettere å forklare til kunden at man har rukket mer i sprinten, enn mindre, mener Cao.