En af de ting, der ofte bliver diskuteret i fora for Agile og Lean, er hvorvidt Teams bør estimere eller ej. Kontroversen findes især – med stærke følelser vedhæftet – indenfor softwareudviklings-miljøer.
I et forsøg på at undgå at placere mig lige i midten af denne stormfulde diskussion, vil jeg i denne artikel i stedet gribe estimering an fra en helt anden vinkel. Mit udgangspunktet her er nemlig at estimering udført på den rette måde kan være en meget effektiv måde for et team at opbygge viden på, på en iterativt måde i et samarbejde med hinanden.
Lad os til at begynde med dog gå ud fra, at der findes situationer, hvor det at estimere indsats, værdi, risici og kompleksitet rent faktisk gør en forskel. At der er situationer, hvor Product Ownere er nødt til at vælge, hvad der skal arbejdes på, baseret på hvor meget værdi det skaber og med hensyn til f.eks. et begrænset budget. Lad os også antage at teammedlemmer kollektivt har en eller anden idé om, hvor meget en opgave kræver baseret på erfaring og at interessenter har holdninger til værdien af de ting, der produceres og at disse holdninger er relevante at tage højde for.
I sådanne situationer er Product Ownere nødt til at prioritere baseret på disse forskellige forventninger og forudsigelser – baseret på estimater. De har ikke andet; fremtiden er her ikke endnu. I sådanne situationer er en eller anden form for forudsigelighed helt afgørende, og jo mere præcis den kan blive jo bedre. Det er derfor i den grad umagen værd at lære, hvordan det gøres.
Værktøjer til Estimering
Traditionelle projektledere opererer ofte med fire værktøjer til at estimere omkostninger:
- Analog Estimering
- Parametrisk Estimering
- Three Point Estimating
- Bottom up Estimering
Disse fire estimeringsmetoder siges at repræsentere en hierarkisk struktur, hvor analog estimering repræsenterer den mindst nøjagtige metode, og Bottom up estimering repræsenterer den mest nøjagtige metode. Læsere kan med fordel selv undersøge disse teknikker nærmere. I forhold til denne artikel er det tilstrækkeligt at sige, at det vi vil fremlægge her rent faktisk er en måde at kombinere alle fire værktøjer på en en brugbar og samtidig billig måde.
Før vi for alvor begynder på forklaringen, vil jeg gerne kommentere på udsagnet om at Bottom up Estimering ses som den ultimative og mest nøjagtige metode. Denne opfattelse bygger nemlig på den antagelse at det arbejde, der skal estimeres, befinder sig i det Ordnede Domæne (Åbenlys eller Kompliceret), hvor der findes tilstrækkelig viden til at løse opgaverne. I mange situationer er dette dog ikke tilfældet og det gør lidt estimeringsindsatsen til spild af tid.
Når det arbejde, der skal gøres, i stedet er komplekst, i situationer hvor der kun er fragmenteret viden tilgængelig, så kræver estimering i stedet samarbejde og sammen at finkæmme og lede efter fælles forståelse og opbygning af viden.
Som en konsekvens af dette, så handler de metoder vi bruger ikke kun om at finde frem til et tal, men ligeså meget om at facilitere samarbejde, og at hjælpe folk med at få delt den viden de har og dermed gøre brug af deres kollektive erfaring.
Når der skal estimeres en bestemt egenskab ved en foreslået projektleverance, så er formålet at udvikle den bedst mulige fælles forståelse blandt de, der er involveret og tager beslutninger indenfor de begrænsninger som tid og budget sætter, så det er muligt at tage kloge beslutninger.
Et par principper at skrive sig bag øret: For det første så skal det gøres i et rimeligt hurtigt tempo. Erfaringen er, at det at bruge mere tid efter den første initiale investering har en tendens til at forringe kvaliteten ved estimeringerne. For det andet – med stigende kompleksitet, så er der typisk en stigende usikkerhed ved de tal, der produceres; det er derfor klogt altid at arbejde med disse tal som intervaller, hvor vi forventer tallet falder indenfor, frem for et enkelt tal.
Vi har for nyligt introduceret en ny version af vores agile kort med kort til forskellige estimerings-scenarier. Lad os nu gennemgå de forskellige metoder.
Estimation Poker
Estimation Poker (EP) eller Planning Poker® er en arbejdsgruppe-metode, som blev populariseret af Mike Cohn fra Mountain Goat Software. Du kan læse mere om dette her…, og der findes endda en online version her… Vi har valgt at bruge en række kort, som er en videreudvikling af den række kort som Mike Cohn skabte. EP kan bruges grupper af folk for at estimere en hvilken som helst numerisk værdi; indenfor Scrum bruges det til at estimere arbejdsindsats, omkostninger og værdi for firmaet.
Processen
For enkelthedens skyld vil vi i det følgende bruge Scrum terminologi og gå ud fra at målet er, at estimere den nødvendige indsats i forhold til at færdiggøre en produktleverance. Følgende er hvordan processen forløber:
- Hvert teammedlem har et sæt kort som dem på billedet..
- Under mødet “Product Backlog Refinement” har Product Owneren (PO’en) fremhævet et antal stories (PBI’er, specifikationer). Ideelt set har Teamet efterfølgende haft mulighed for at sætte sig ind i de forskellige stories.
- PO’en fremlægger de forskellige stories,Teamet stiller spørgsmål og en dialog finder sted. Alle forsøger at forstå, hvad dette handler om og undgår at komme med udtalelser om størrelse, da dette uundgåeligt vil påvirke andres vurderinger.
- Når diskussionen stilner af, bliver Teamet bedt om hver især at give deres bedste bud på et estimat. Hvert Teammedlem vælger et kort og viser det til hinanden samtidigt. Det gøres samtidigt for at undgå at påvirke hinanden. Estimatet er baseret på en sammenligning med nogle reference emner som Teamet på forhånd er bekendt med. Teamet kan have brug for at have referencer til arbejde på str. med 2, 5 og 13 (lille, medium og stor). Hvad er hver enhed så målt i? Det kan være i absolut tid (en ideal arbejdsdag for en mand for eksempel) eller det kan være i den relative måleenhed “Story Points”, sådan at 5 er ca. 2½ gange større end 2. (I denne artikel bruger vi Story Points i senere eksempler.)
- Baseret på de estimater, der bliver vist, vil folk nu give deres begrundelser for estimeringerne. Det er almen praksis at lade, de der har de mest ekstreme værdier begynde. Det vil sige, at hvis det største tal, der er blevet lagt er 8, så skal den person, der har lagt dette, begynde med at forklare. Den, der har givet det laveste estimat, for eksempel 2, er den næste, og efterfølgende må de resterende byde ind med deres synspunkter.
- Når diskussionen igen stilner af, samles kortene op igen og endnu en omgang estimering udføres. Hvis Teamet kan blive enige om et tal, så er omgangen færdig for det givne emne, hvis ikke tages der endnu en runde med diskussion. I sidste ende kan Teamet vælge at følge flertallet.
- Det kan ske, at Teamet ikke kan finde frem til en konklusion. I dette tilfælde kan emnet lægges til side til yderligere research, analyse eller eksperimentering før der forsøges at estimere igen.
At tilføje usikkerhed
En meget god udvidelse ift. standard estimation poker er at tilføje en vurdering af usikkerhed.
- Når man beder folk om at give det “bedste estimat”, så forstås det ofte som et “50% estimat” i statistiske begreber, hvilke betyder at de, der estimerer, anser det som lige sandsynligt at det endelige resultat bliver mindre, som at det endelige resultat bliver større.
- Så et enkelt trick for at tilføje en måde at måle usikkerhed på, er at bede Teamet lige efter deres første estimat om at tænke på “det værst tænkelige scenarie”. Det ses ofte, at når folk bliver bedt om at tænke på det værst tænkelige scenarie, så tænker de for det meste ikke på tsunamier, jordskælv og andre ekstreme events, men i stedet tænker de på manglende afklaringer, usikker teknologi osv. Det er alment accepteret, at når der bedes om det værst tænkelige scenarie, så resulterer det ca. i et 90% estimat, hvilket betyder at vi med 90% sikkerhed tror på, at det ikke kan gå værre end dette.
- Ofte udfører Teams derfor kortspillet som beskrevet ovenfor og inkluderer 90% estimatet også. Hvis resultatet af kortspillet for 50% estimatet var at ca. halvdelen af team medlemmerne sagde “5” og den anden halvdel sagde “8”, så er det helt okay for Teamet at sige “Kan vi blive enige om 5 for 50% estimatet og 8 for 90% estimatet?” Det handler om at Teamet får mulighed for at udtrykke deres ærlige mening.
- I følge vores egen erfaring, så hjælper brugen af denne udvidelse Teamet med at nå til enighed. De behøver ikke nødvendigvis komme frem til et enkelt tal men kan i stedet give et interval.
- Det kan være en hjælp for PO’en netop at bruge denne måling af usikkerhed proaktivt i sin prioritering. Han har mulighed for at trække højrisiko opgaver op til toppen af backloggen, for at undgå for meget usikkerhed allerede tidligt i projektet. Han kan også vælge at udskyde sådanne opgaver, som der er usikkerhed omkring for for eksempel i stedet af nå en vigtig deadline, eller for at kunne indsamle mere viden om opgaven så usikkerheden evt kan reduceres senere. I sidste ende kan blot det at opdage, at der er stor usikkerhed omkring en bestemt Story udløse vigtige diskussioner mellem Teamet, Product Owneren og interessenterne.
- Når et sæt stories er blevet estimeret på denne måde, så kan usikkerheden for det givne sæt udregnes ved brug af standard statistiske teknikker. 50% procents estimatet for sættet er summen af de individuelle estimater. For at opnå 90% estimatet for et sæt af uafhængige stories, så tillægges en 90% buffer til summen af 50% estimatet og denne buffer beregnes som kvadratroden af summen af kvadrattal af individuelle differencer mellem 50 og 90 procents estimaterne.
E90 = E50 + SQRT( (A90-A50)^2 + (B90-B50)^2 … (Z90-Z50)^2 )
De forskellige kort
En pakke kort til Estimation Poker er et udvidet sæt kort med kort til flere forskellige formål:
- 1, 2, 3, 5, 8, 13: De kort der bliver brugt til Stories, som traditionelt set anses for at være en passende størrelse til at kunne implementeres i et Sprint. Tallene hedder Fibonacci-tal, og der er bred erfaring for at de stigende spring mellem størrelserne fremskynder estimeringsprocessen.
- 0, ½: Til mindre stories, som der måske kan være fordele ved at kombinere med nogle lidt større.
- 20, 40, 100: Virkelig store Stories, ofte kaldet Epics. Et estimat som dette er en indikation på at en sådan story skal nedbrydes yderligere. Det bør også forstås som et meget upræcist estimat. Mennesker kan tilsyneladende kun estimatere inden for én størrelsesorden.
- ?: Dette kort er for folk som ikke har nogen anelse om, hvad der bliver diskuteret. Den bør ikke bruges bare fordi nogen synes at en anden person sikkert ved mere.
- Kaffekop: Timeout, en pause, når nogen ikke kan fortsætte.
Konceptet bag Story Points
Folk kæmper ofte lidt med konceptet bag Story Points eller relativ estimering i forhold til reference stories. Da den virkelige verden opererer udfra tid og penge, hvorfor så gøre det anderledes her? Her er nogle strøtanker:
- Ved at gøre brug af et relativt mål og ikke en absolut tidsenhed, opnår vi det at adskille vurdering af størrelse fra forpligtelse, hvilket giver et mere objektivt estimat.
- Ved at dreje folks opmærksomhed over på reference stories, så eliminerer vi nogle af de negative konsekvenser fra de kognitive skævvridninger, der opstår når man skal estimere ens eget arbejde .
- Når der estimeres i story points, så giver det mening at spore Teamets hastighed, med andre ord hvor mange story points Teamet kan levere per Sprint. Det kan være brugbart til at lave forudsigelser i relativt stabile miljøer, det er også nyttigt i forhold til at vurdere hvorvidt ændringer Teamet laver på deres arbejdsmåder har en positiv virkning.
- Hvis Teamets hastighed ændrer sig, så er estimaterne i story points stadig valide og behøver ikke laves om.
- Når der estimeres ved brug af story points, så er Teamet nødt til at have nogle referencer at sammenligne de stories der skal estimeres med. Der er flere måder at få de referencer på. Det kunne være jobs som Teamet allerede har udført sammen og kender størrelsen af; det kunne være nogle af de stories som Teamet vælger at udføre for at skabe en baseline og det kunne være nogle “arbejds-bidder” som Teamet har en fælles forståelse af. Mens Teamet levere flere stories senere, vil de have in mente at vælge gode referencer til fremtidig brug.
Ekstra anbefalinger
Nogle folk foretrækker at anvende gennemsnit, når Teammedlemmer stiller med forskellige estimater. Praksissen frarådes, fordi det tillægger et indtryk af præcision som typisk ikke er berettiget i stabil viden. Det kan derfor forlede interessenter til at sætte for stod en lid til estimaterne.
Nogle folk tillader Team medlemmer at bruge to kort til estimering, men det er ikke anbefalet. Formålet med estimaterne er at vise interessenter at dette drejer sig om grove skøn, at tillægge yderligere detaljer slører dette indtryk, ligesom brugen af gennemsnit som nævnt tidligere.
Andre anvendelser af Estimerings Poker
Estimerings Poker kan også bruges til andre formål. Den mest oplagte brug er at bruge det til at estimere Business Value (Forretningsværdi), i det tilfælde er det naturligvis forskellige mennesker der udfører det, interessenterne eller brugerne – de der har en mening om værdien. Hvis der estimeres værdi, er det naturligvis nødvendigt med referencer af værdi og de værst tænkelige estimater er selvfølgelig mindre end estimaterne for de bedst tænkelige.
Hvorfor denne metode er nyttig
Idéen omkring at estimere i Teams på denne måde, hvor der er et begrænset sæt udfaldsmuligheder har en række forskellige praktiske fordele/nyttige virkninger:
- At estimere i et Team skaber med det samme et fokus og form for gensidig ansvarlighed, der gør, at folk tager opgaven mere seriøst.
- At estimere i et Team har også en tendens til at fjerne de værste misforståelser og dermed de virkelig store estimeringsfejltagelser, fordi flere folk med forskellige perspektiver er involveret.
- At estimere i et Team giver en form for beskyttelse imod de mest almindelige kognitive skævheder (cognitive biases). Daniel Kahneman har undersøgt mange af disse og fra ham kan vi lære, at det at involvere flere folk i at lave en vurdering kan forhindre nogle af de mest negative konsekvenser af de mest udbredte biaser.
- Ved at have et begrænset sæt af udfaldsmuligheder, bliver processen accelereret, og der er mindre risiko for at bruge for meget tid og devaluere resultaterne ved at overfokusere på en enkelt synsvinkel.
- Hele Teamet er involveret, dette forbedre sandsynligheden for at Teamet tager psykologisk ejerskab for resultatet sammen. Det er ikke kun eksperten eller den person der plejer at udføre det arbejde, som udtrykker sin mening.
Hele metoden er en måde at involvere alle på og fremprovokerer at folks viden kommer frem til overfladen. Vi kan ikke bare sige det, vi ved på kommando, for “vi ved kun, hvad vi ved, når vi har brug for at vide det.” (Dave Snowden) Det er selvfølgelig nyttigt at tilegne sig nogle tal at arbejde med, men det er mindst lige så brugbart at have sådan en arbejdsgruppe-metode, som sætter folk i stand til at opnå en fælles forståelse. Estimering set som en indsats i fht. vidensopbygning er IKKE spild, det er også måde at arbejde sig igennem processen med det formål at nå til en rimelig robust fælles forståelse.
Denne artikel vil blive opfulgt af en anden, hvor vi beskriver vores nye udvidede Extended Agile Cards, som indeholder Estimerings Poker, T-Shirt Estimering, Cynefin Estimering, Kano Estimering og Tillids-estimering, hold øje med dette.
