Estimering
Estimering er en helt naturlig del av prosjektstyringsfaget – vi må jo vite hva det kommer til å koste og når vi kan forvente å være ferdig! Alle metoder og rammeverk som forutsetter å legge en plan mot et mål – for deretter å følge opp mot denne planen – er helt avhengig av gode estimeringsteknikker.
Smidig tankesett og Scrum er først og fremst for problemområder med stor usikkerhet og kompleksitet der vi må manøvrere i retning av målet gjennom læring og feedback. Vi vet at vi kommer til å oppdage interessante ting på veien og at viktige antagelser kan vise seg å være gale, så suksess har ingen ting å gjøre med vår evne til å følge planen. Dette er mao ikke først og fremst et prosjektstyringsproblem. Så da er det vel helt unødvendig å estimere noe som helst? Det er ingen overdrivelse å si at estimering under slike betingelser er kontroversielt. Utviklere sier typisk slikt som:
Hvorfor i det hele tatt forsøke når usikkerheten er så stor?
Demotiverende å stadig oppleve at estimatene var feil
Vi blir tvunget til å estimere for at ledelsen skal kunne følge oss opp!
Hvorfor skal vi bruke tid på noe så unyttig!
Dette er forståelig og gode poenger, men vi kan allikevel ikke bare vri oss unna dette helt. Vi trenger faktisk å forholde oss til fremtiden selv om denne er usikker og det er helt nødvendig å ta med “antatt arbeidsmengde” når vi skal prioritere og ikke minst legge strategier. Vi skal her se litt på ulike teknikker muligheter som vil gi verdi uten at det koster for mye.
Prioritering
La oss tenke oss at Product Owner jobber tett sammen med interessenter, og at de blir enig om en ny feature som vil generere mye verdi. PO lager skisse til et Product Backlog Item (PBI) og tenker at denne her må høyt opp i Product Backlog! Det er helt fint, men det kan jo hende at denne POen antar at “dette kan da ikke være så mye jobb”. Men tenk om utviklerne vet at, joda, dette er faktisk en god del arbeid. Skal vi få til dette må vi redesigne viktige komponenter i tjenestelaget og sannsynligvis skrive mange hundre kodelinjer!
Da vil jo PO se på denne nye funksjonaliteten med nytt blikk, og trigge spørsmålet “hvor mye sånn ca vil det koste?” Med andre ord be om et estimat. Kanskje den ikke er så lovende allikevel? Kanskje dette vil koste så mye at det er tvilsomt om det er verdt investeringen? Så, her må utviklerne og PO sette seg ned og luke ut slike sprikende antagelser. Kanskje det finnes måter å gjøre funksjonen enklere så det ikke blir så mye jobb? I Scrum gjør vi dette i Product Backlog Refinement (PBR).
Enkelte ting kan være av typen “koste hva det koste vil”. Dette er egenskaper eller funksjonalitet som bare MÅ være tilstede. Er det da nødvendig å grovestimere? Ja, det er fremdeles av stor verdi å vite noe grovt om hvor mye tid denne saken vil beslaglegge. La oss si at denne ene saken blir utviklernes eneste oppgave i flere Sprinter på rad. Da vil andre presumtivt viktige saker bli satt på vent. Vi går her glipp av identifiserte gevinster hver eneste dag faktisk, så om ikke annet må PO ha denne informasjonen for å kunne forventningsstyre ift interessentene.
T-skjorte estimering
Dette er kanskje ikke estimering i vanlig forstand, snarere en kategorisering. Allikevel noe som gjør at utviklerne må diskutere forståelsen av en PBI og så si noe grovt om størrelsen på jobben. Skal ikke ta veldig mye tid og blir ikke særlig nøyaktig. Men MYE bedre enn ingenting!
Planning Poker
Dette er en metode som er litt mer sofistikert enn T-skjorte metoden. Vi bruker her en tallskala som er mer finkornet basert på Fibonacci som representeres på fysiske (eller virtuelle) kort. Det finns en del varianter men de fleste har følgende skala: 0,1,2,3,5,8,13,20,40 og 100. Bemerk at Planning Poker bør spilles med streng 2-minutters tidsboksing, og følger man dette vil hva som helst kunne estimeres av et team på maks 14 minutter.
Du kan finne kortstokker og lese mer om denne teknikken her: https://smidigkurs.no/produkt/planning-poker-kort/
Strategisk planlegging
Hvordan vet vi om vi har de kapabilitetene vi trenger for å nå neste Produktmål? Har vi nok fart, eller bør vi skuffe på mer køl? Hvordan ser den sannsynlige framtiden ut basert på det vi vet i dag? Vi må stille oss disse spørsmålene selv om usikkerheten er stor.
Velocity
Selv om dette ikke lenger er en del av Scrum, blir det knyttet til Scrum og svært ofte med negativt fortegn. Og det er forståelig, siden det ofte blir misbrukt. Men brukt riktig, kan dette faktisk være til god hjelp.
Velocity forteller som navnet indikerer noe om teamets fart. Hvor “mye” lager dette teamet per Sprint? Dette gir oss da historikk for et bestemt team, noe som kan være veldig nyttig når vi skal forsøke å spå om framtiden. En slags krystallkule med andre ord.
Det ER ekte vanskelig å uttale seg med noen grad av sikkerhet om framtiden – men det betyr ikke at det er verdiløst å forsøke.
Velocity hviler på noen forutsetninger:
- Et ganske stabilt team
- At alle estimater er relative til en referansesak som alle kjenner
- Sprinter med fast lengde
- At vi er komfortable med usikkerhet og det faktum at vi ikke har all informasjon tilgjengelig
- At det ikke foreligger noen som helst form for belønning for å øke farten eller at man blir målt på presisjonen.
Dette kombinerer veldig godt med Planning Poker, men man kan også bruke T-skjorte metoden.
Grafen forteller bare at med dette teamet er det sannsynlig at vi kan holde en gjennomsnittsfart på 36. Dette trigger da spørsmålet – “er dette tilstrekkelig?” Skal vi øke ambisjonsnivået og dermed kostnadene for å få høyere fart? Eller kanskje vi kan bremse opp litt og ta ut et par teammedlemmer og heller bruke de på et mer strategisk viktig produkt? Velocity gir også et godt grunnlag for å lage et veikart (road map) for produktet slik at man kan ha gode strategiske diskusjoner om produktet og markedet.
Sprint status
Scrum er jo basert på at alt arbeidet gjøres i Sprinter med et klart mål. Vi forutsetter at i en Sprintperiode (1-4 uker) har vi noenlunde kontroll og et noenlunde stabilt utviklerteam. Vi forventer ikke store overraskelser i denne perioden, men vi lever fint med noe usikkerhet.
Så hvordan kan da et team ta “riktig” mengde arbeid inn i en Sprint? Hvordan kan de evaluere sin egen framdrift underveis og uttale seg om de vil nå Sprintmålet eller ikke? Både PO og interessenter vil gjerne vite så tidlig som mulig om Sprintmålet er innen rekkevidde eller ikke. Det viser seg i praksis at dette er svært vanskelig for urutinerte team (uansett hvordan man angriper det), men helt overkommelig etter en del Sprinter.
I tidligere versjoner av Scrum Guiden var det krav til at man under Sprint planlegging delte opp PBI-ene i oppgaver og estimerte disse. Deretter skulle utviklerne lage burndown-graf som viser daglig gjenstående arbeid opp mot gjenstående kapasitet.
Sprint burndown er ikke lenger en del av Scrum – siden det er flere måter å angripe dette på. Ikke dermed sagt at det er en dårlig ide, det tar ikke mange minuttene hver dag å oppdatere dette.
Alternativt, i stedet for å estimere kan man bare telle antall gjenstående oppgaver og lage en burndown ut fra dette. Andre utviklerteam vil bare sørge for at PBIene er såpass små at man bare kan telle antall gjenstående og lage en tilsvarende graf uten å estimere. Mange muligheter!
Epilog
Scrum krever svært lite når det gjelder estimering – kun at man er i stand til å gjøre kost/nytte vurderinger og å lage en grov prognose. De som skal gjøre jobben må altså bruke litt innsats på å forsøke å si noe om fremtiden – både på kort og lang sikt – uten å bruke for mye tid og energi på det. Her er noen punkter som kan være til hjelp:
- Vi estimerer ikke for å “få rett”. Vi estimerer for å si noe om en sannsynlig fremtid basert på den informasjonen vi har i dag. En prognose.
- Ikke bruk estimering til oppfølging. Suksess har ingen ting med estimeringspresisjon å gjøre.
- Estimer som team – så langt det er mulig. En nyttig bi-effekt av dette er at man får antagelser på bordet og at det “bygger team”.
- Estimer med tidspress.
- Lev med grove anslag og usikkerhet.