Estimering er et af de mest kontroversielle emner inden for produktudvikling. Hvorfor? Fordi teams frygter at blive holdt ansvarlige for tal, der i sagens natur er usikre. Nogle indregner sikkerhedsmargener for at “beskytte” sig selv, mens andre mener, at det er meningsløst at estimere komplekse opgaver.
Målet med relativ estimering er simpelt: bedre samtaler om problemet. Product Owner’s opgave er at maksimere afkastet af investeringen ved at afveje forretningsværdien i forhold til arbejdets omfang og kompleksitet. Spørgsmålet er: “Hvor meget værdi kan jeg få ud af denne investering?” Relativ værdiansættelse tager højde for begge dele af denne ligning – værdi og investering.
Planlægning af poker er den faciliteringsteknik, der gør dette muligt. Den sikrer, at hvert teammedlems mening tæller, samtidig med at processen forbliver effektiv. Holdene bruger fysiske kort eller smartphone-apps med en Fibonacci-lignende rækkefølge: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? – og ☕.
Planning Poker kan bruges af teams og deres Product Owner til at få en forståelse af investeringen, og den kan anvendes af Product Owner i samarbejde med interessenterne for at nå til enighed om forventet forretningsmæssig værdi. For begge grupper er fremgangsmåden den samme.
Hvorfor det giver mening at anvende relative skøn
Teammedlemmer tøver ofte med at komme med skøn, fordi deres tal bliver betragtet som bindende forpligtelser – uanset hvilke antagelser der ligger til grund, eller hvilke overraskelser der måtte opstå senere. For at “beskytte” sig selv lægger de buffere til eller ganger skønnene med en faktor (undertiden π, for at få det til at se videnskabeligt ud). Men at stable buffere oven på hinanden mindsker gennemsigtigheden og gør skønnene ubrugelige.
Det tager tid at udarbejde præcise estimater, men den ekstra indsats betaler sig sjældent. Estimater vil aldrig være 100% nøjagtige, så det giver ofte bedre resultater at bruge mindre tid på at estimere og mere tid på at levere. Relativ estimering tager højde for dette: det handler om størrelse og kompleksitet, ikke timer. Vi kalder det story points.
Ved relativ estimering behøver man ikke være præcis; man skal blot være konsekvent i, hvor dårlige ens skøn er. Samtidig hjælper relativ estimering teammedlemmerne med at dele deres forståelse af den opgave, der skal udføres, og blive enige om, hvor stor den er.
Hvorfor er det sådan?
Sagen er den, at Peter, Paul og Mary ikke er lige dygtige til at udføre visse opgaver. Nogle opgaver kan Peter udføre hurtigere end Paul – fordi han har mere erfaring på det område. I andre opgaver er Paul hurtigere end Mary – og i andre er det Mary, der er hurtigst. Samtidig svinger Marys motivation og energi – nogle dage er hun fuld af energi, andre dage er hun helt udmattet. Måske sov hun ikke godt i nat. De dage, hvor hun er fuld af energi, får hun meget fra hånden; de dage, hvor hun ikke er det, går arbejdet næsten i stå. Mennesker er ikke robotter. Vores arbejde er ikke-lineært – interaktioner og resultater varierer.
For at udligne dette bruger vi story points. Med story points kan Peter, Paul og Mary blive enige om, at én opgave er en 5’er, en anden en 13’er og en tredje en 8’er – selvom Peter er bedst til den første, Mary til den anden og Paul til den tredje. Er det en eksakt videnskab? Nej. Men det udligner sig med tiden. Det er som en rutsjebane – nogle gange vinder man, andre gange taber man. At vurdere omfanget af komplekse opgaver har aldrig været – og vil aldrig blive – en eksakt videnskab.
For at adskille story points fra tidsforbruget skal teamet have en henvisning baseret på det arbejde, de allerede har udført – vi kalder normalt disse for »user stories«. De opbygger denne reference ved at sammenligne forskellige arbejdsopgaver med hinanden. Hvilken er en 3, hvilken er en 5, og hvilken er en 8? Teamet bør vedligeholde og forfine sin reference over tid, samtidig med at det sikrer, at referencen ikke glider ud af kurs.
En metafor til at forstå story points
Lad os tage en simpel opgave: at flytte en bunke sand. De to personer, der skal udføre denne opgave, kan stort set blive enige om dens volumen (størrelse) – og de kan også blive enige om, hvor kompliceret det er at flytte den. For at være ærlig er det ikke så kompliceret at flytte sand – medmindre sandet er forurenet, hvilket gør opgaven mere kompliceret, fordi det vil kræve særlig håndtering og udstyr.
Opgaven med at flytte sandet har en bestemt kombination af omfang og kompleksitet – man kunne sige, at denne opgave er en 8’er. Hvis det havde været forurenet sand, kunne det have været en 13’er eller en 20’er. Det siger dog ikke noget om, hvor lang tid det vil tage. Det afhænger af, hvordan opgaven bemandes. Hvis én person flytter sandet, tager det en vis tid; hvis to personer gør det, vil tiden være anderledes (forhåbentlig kortere). Måske er de to personer ikke lige dygtige til at flytte sand. Måske har den ene ondt i ryggen – så vil det tage længere tid, hvis den person arbejder alene. Hvis den anden person gør det, går det hurtigere. Måske varierer redskaberne – den ene dag bruger de spande, den næste dag trillebøre og den tredje dag en gravemaskine. Tiden vil variere, men kombinationen af størrelse og kompleksitet forbliver den samme. Det er stadig et 13, uanset hvor mange personer der udfører arbejdet, eller hvilke redskaber de bruger.
Det er ikke en eksakt videnskab, men med tiden udligner det sig – især hvis man holder referencegruppen og holdet stabilt.
Hvordan man spiller
I starten af Planning Poker får hvert teammedlem et kortspil. For hver brugerhistorie eller hvert tema, der skal estimeres:
- En moderator – typisk en Product Owner, Scrum Master eller analytiker – læser beskrivelsen op. Den Moderatoren stemmer ikke.
- Hvert teammedlem vælger i al hemmelighed en kortværdi ud fra deres forståelse af historien, når de sammenligner den med den reference, holdet har henvist til.
- Når alle har valgt, vises alle kort på én gang.
- De holdmedlemmer, der har højeste og laveste værdier redegøre for deres ræsonnement.
- Product Owner eller interessenten besvarer eventuelle spørgsmål fra teamet.
- Hvert teammedlem reviderede skøn ved at vælge et nyt kort privat.
- Alle kort vises igen, så alle kan se de opdaterede skøn.
- De holdmedlemmer, der har de højeste og laveste værdier drøfte deres begrundelse endnu en gang.
- Efter drøftelsen foretager hvert teammedlem en ny tidsvurdering.
- Hvis der kun er en forskel på ét trin blandt de resterende kort, den den højeste værdi vælges.
- Hvis der er Der er stadig ingen enighed efter tredje runde, det den højeste værdi vælges.
Brug af Planning Poker til at skabe forretningsværdi
Processen er den samme, når det drejer sig om forretningsværdi. Her foretager Product Owner og de relevante interessenter den relative vurdering. Ligesom teamet har en referenceramme for story points, bør Product Owner og interessenterne have en referenceramme for forretningsværdi – helst funktioner, der allerede har bevist deres værdi på markedet.
Under vurderingen bør deres dialog om forretningsværdien ikke kun dreje sig om penge. De kan f.eks. drøfte:
- Vil denne funktion åbne op for nye markeder for os?
- Kan det hjælpe os? upselling til eksisterende kunder?
- Er det nødvendigt at beholde vores markedsposition?
- Vil det blive bedre? effektivitet?
- Er dette et krav i henhold til lovgivning?
- Vil det styrke vores mærke?
Ingen af disse aspekter er i sig selv bedre end de andre, men det er diskussionen og samordningen, der er afgørende.
Anvendelse af relativ estimering til prognoser
Formålet med at lave estimater er at udarbejde forudsigelige planer. Det er næsten umuligt, når man arbejder med komplekse opgaver – men det bør ikke afholde os fra i det mindste at forsøge. Uanset hvor Agile vi tror, vi er, er der stadig brug for synkroniseringspunkter som milepæle eller gates. Andre afdelinger – såsom produktion, salg eller marketing – er afhængige af at vide, hvornår vi er færdige med at udvikle en funktion eller et produkt. Selvom planerne vil ændre sig, bør vi stadig give vores bedste skøn på hvad der vil ske og når vi er færdige.
Ved at anvende relativ estimering med story points og samtidig måle, hvor mange story points teamet leverer i hvert sprint (deres velocity), kan Product Owner foretage noget forudsigelige planer. Da teamet er villigt til at vurdere opgaver i Product Backlog – selvom de kun er kort beskrevet – bliver det en enkel opgave for Product Owner at udarbejde et udkast over, hvilke opgaver der sandsynligvis passer ind i de enkelte sprints. Dette skaber gennemsigtighed omkring planer og fremskridt, hvilket hjælper Product Owner med at drøfte prioriteter med interessenterne og træffe de bedst mulige beslutninger.
Den største udfordring ved at anvende hastighed er, at den varierer over tid. Flere faktorer har indflydelse på dette:
- Teammedlemmernes tilgængelighed i forbindelse med samarbejdet
- Afbrydelser i det daglige arbejde
- Forskelle i, hvor godt holdets kompetencer passer til de aktuelle opgaver
- Teammedlemmernes fokus og engagement i at nå Sprint Goal-målet
En god måde at håndtere denne usikkerhed på er at bruge 90% Konfidensinterval af hastigheden. Selvom der ligger statistiske formler til grund for dette, bruger man i praksis den næsthøjeste og den næstlaveste hastighed ud fra de seneste otte sprints for at fastlægge intervallet, der skal danne grundlag for den fremtidige hastighed.
Nogle teams indregner en buffer i sprintet til uforudset arbejde. Men når man anvender relativ estimering med story points og baserer forpligtelser og prognoser på den målte hastighed, betyder det Denne buffer er allerede medregnet. Hvis et team planlægger arbejdet ud fra sin aktuelle hastighed, er den nødvendige buffer automatisk indregnet.
Det er ikke en eksakt videnskab, men med tiden udligner det sig – især hvis man holder referencegruppen og holdet stabilt.
Afsluttende tanker
Brug af relativ estimering er en enkel måde at håndtere kompleksiteten i produktudviklingen i en moderne verden på. Evnen til at gøre dette kommer dog ikke ud af den blå luft – der er en lang række forudsætninger, der skal være opfyldt, for at det kan fungere. Disse omfatter:
- En klar forståelse af og følelse af ansvar for holdets formål og mål
- Team stabilitet og indbyrdes sammenhænge
- Holdets enighed om roller og ansvarsområder
- Product Owner’erne mandat og disciplin i forfining af ordrebeholdningen
- Scrum Master’s evne til at beskytte holdet fra uplanlagt arbejde
Som I kan se, er der en struktur og en proces forbundet med brugen af relativ estimering, men i sidste ende handler det om kultur. Relativ estimering fungerer kun, hvis man accepterer usikkerheden ved komplekse opgaver og giver teamet frihed til selv at træffe beslutninger om, hvordan opgaven skal løses. Hvis man hele tiden ændrer teamets sammensætning, vil det aldrig fungere.
