Planning poker – også for de uten pokerfjes

Smidige metoder

8 min. lesning

Smidige prosjekter byr på masse spenning og dynamikk – til og med i form av kortspill. Agile team har derfor innsett at de ved siden av å skrive kode også kan more seg på jobb med å spille en form for poker. Poker har en lang og noe lyssky historie. Men i den smidige prosjektverden har dette kortspillet et helt annet formål enn å vinne motspillerens poker-chips. I et smidig perspektiv brukes poker til planlegging av oppgaver som gjenstår å fullføre. Så her kan man ikke forvente en royal flush, og det kan spilles uten å bruke solbriller – for de som ikke har pokerfjes.

Planning Poker, også kjent som Scrum Poker og Estimation Poker, er en planleggings- og estimeringsteknikk for å avstemme hvor mye arbeid og tid som er nødvendig for å fullføre gjenstående oppgaver i en produkt-backlog. Dette har fått betegnelsen «Poker» på grunn av at alle benytter fysiske kort som likner spillekort. I vår tid finnes det selvfølgelig apper som kan brukes som et alternativ til spillekort.

I en hektisk smidig leveranse kan estimeringsarbeidet for en stor backlog ofte bli skjøvet på. Men i stedet for å utsette dette arbeidet må det prioriteres og betraktes som en investering som i det lange løp vil være tidsbesparende for prosjektet. Smidige team bør starte med planleggingsarbeidet så fort produkt-backloggen er etablert for prosjektet. Estimering av en produkt-backlog kan være en tidkrevende øvelse siden den kan være veldig stor, men i slike situasjoner kan arbeidet deles opp i flere runder med planlegging.

1. Spillets gang - hvordan foregår Planning Poker?

Planning poker, eller estimeringspoker, spilles av det smidige teamet; scrum master, produkteier og utviklingsteamet. Hver spiller disponerer en hel kortstokk og verdiene på kortene representerer enten et nummer for brukerhistorien, ideelle dager for å fullføre oppgaven eller en annen enhet som teamet blir enige om.


Hold deg oppdatert på hva som skjer i smidigverden - abonner på smidigbloggen.


Spillekortene i Planning Poker

Alle spillekortene i kortstokken har en numerisk verdi basert på Fibonacci-sekvensen. Det vil si at hvert påfølgende nummer i serien er summen av de to foregående numrene - 0, 1, 1, 2, 3, 5, 8, 13, 21, 34. Denne sekvensen sikrer et konsistent forhold mellom kortene som brukes. Det finnes også estimeringskort som benytter sekvensen; 0, 1, 2, 3, 5, 8, 13, 20, 40 og 100. For å gjøre estimeringsprosessen enda mer spennende har noen kortstokk tre kort med symbolene uendelig (Ꝏ), et spørsmålstegn (?) og en kaffekopp (☕). Nummerverdien på kortene representerer altså den mengde arbeid og tid en oppgave i backlogen antas å ta for å fullføre. Symbolkortene (Ꝏ, ?, ☕) representerer henholdsvis; «stor oppgave som ikke kan gis en verdi», «usikker på oppgaven», og dette var ikke lenger så spennende og «trenger en pause/kaffe».

Spillets regler – hvordan brukes kortene

Produkteier eller kunde starter med å lese opp en brukerhistorie. Teamet diskuterer deretter denne brukerhistorien og stiller nødvendige spørsmål for å avklare uklarheter og utfordringer. Når teamet har fått tilstrekkelig informasjon velger de ett kort fra sin kortstokk som de mener representerer estimatet for denne konkrete brukerhistorien.

Det er viktig at teammedlemmene viser frem sine kort samtidig. Om alle viser frem samme verdi på kortene blir dette gjeldene estimat for brukerhistorien. Dersom det er ulike estimater fra teamet må det diskutere valgene som er gjort og det enkelte teammedlem bør begrunne sitt estimat. For å begrense tidsbruken på diskusjonen kan de som har valgt det laveste og høyeste estimatet forklare sine valg.

Denne diskusjonen bidrar til å gi hele teamet ny informasjon og forståelse for skjulte utfordringer for å ferdigstille oppgaven. Etter denne samtalen gjentas estimeringen for samme brukerhistorie og teammedlemmene velger igjen ett nytt kort og viser det frem samtidig. Denne prosessen gjentas til teamet oppnår konsensus eller at teamet blir enige om å avvente estimeringen for denne brukerhistorien inntil de har mer informasjon.

Bakgrunnen for å skjule estimeringskortet og vise det frem samtidig skyldes vårt kognitive system for påvirkning fra andre. Dersom teammedlemmene viser frem sine kort i en rekkefølge, kan den første verdien sette presedens og danne et mønster for etterfølgende estimater. Ved å vise verdier samtidig er det større sannsynlighet for å få ærlige estimater som ikke er påvirket av andres oppfatning. Denne tilnærmingen gir dermed en mer realistisk vurdering av oppgaven.

2. Gevinster med Planning Poker estimering

Blant alle mulige verktøy kan det virke noe underlig å bruke Poker for estimering av oppgaver i et prosjekt. Men dette verktøyet har vist seg å være effektivt for å gi realistiske og nøyaktige tidsrammer, planlegge arbeidsflyt, og etablere konsensus i en tverrfaglig gruppe.

Effektiv arbeidsnedbrytning

Det er velkjent at store arbeidsoppgaver løses best ved å bryte de ned i mange små deloppgaver og fokusere på én oppgave om gangen. Planning Poker sørger for at smidige team kan bryte et prosjekt ned i mindre deler slik at det blir overkommelig å vurdere tidsrammen som er nødvendig for å fullføre hver del. På denne måten planlegger teamet hvor mye tid de trenger for å løse alle oppgaver for hele prosjektet.

Total planlegging av prosjektet blir følgelig den største gevinsten med Planning Poker. Men denne øvelsen gir også teamet et bilde av estimater for oppgaver relativt til hverandre. Relative forhold bidrar til å gi en indikasjon på tidsbruken for oppgaver som henger sammen.

Etablering av benchmark basert på erfaring

I enkelte tilfeller er det vanskelig, om enn umulig, å estimere hvor lang tid en oppgave kan ta for å fullføre. Dette gjelder spesielt om man ikke har gjort en liknende oppgave tidligere. Men desto mer man estimerer med denne teknikken, desto større erfaring får en med å vurdere tidsperspektivet for å løse ulike oppgaver. Dermed - selv om utviklere får en brukerhistorie som de ikke har løst tidligere vil de på bakgrunn av tidligere erfaringer ha en referanse og et sammenligningsgrunnlag som de kan bruke som en «bechmark».

Planning Poker bidrar til å vurdere ressursbehovet for å fullføre en oppgave. Om nødvendig kan teamet få tilført ressurser for å ferdigstille oppgaver. På denne måten unngår man situasjoner med mangel på eller et overskudd av ressurser.

Økt samspill i teamet

Sist, men ikke minst: Moralen i et team får en «boost» ved at alle opplever å bli hørt. Det enkelte teammedlemmets mening har en betydning og vekt. Dette oppmuntrer til ulike meninger i teamet og det kommer innspill og tilbakemeldinger som gir et større grunnlag for å vurdere oppgavene bedre enn om vi kun fikk frem homogene synspunkter. Resultatet av denne inkluderingen er at alle blir hørt og får et eierskap til planleggingen, som i sin tur fører dette til at flere yter bedre for å nå målsettingen med planleggingsarbeidet.

3. Hva med ulempene?

Vil det si at Planning Poker bare har positive sider ved seg? Det er nok rimelig å anta at denne estimeringsteknikken ikke er helt perfekt. Blant annet er målsettingen om konsensus ikke så enkelt å oppnå. Med en stor backlog som skal vurderes og begrensninger på tid kan det medføre at smidige team inngår et kompromiss for å komme frem til en verdi for oppgaven. Utilstrekkelig informasjon om oppgaven kan i sin tur resultere i at verdien som teamet har kommer frem til er gjort på feil grunnlag.

Sterke personligheter i et team kan også tendere til å dominere i prosessen og på denne måten bidra til et feilaktig estimat. I lys av feilaktig estimering kan overoptimisme i gruppa gi en bedre verdi for oppgaven enn konklusjonen fra medlemmene individuelt. Dynamikken i gruppa kan dermed føre til at medlemmer blir overbevist om at oppgaven er enklere enn den faktisk kan være. Gruppetenkning gir en risiko for at teamet påtar seg et større ansvar enn hva det er i stand til å levere innenfor den avgrensede tidsrammen. Fasilitatoren må i denne typen estimeringer sørge for å kontrollere og strukturere prosessen godt gjennom blant annet å avgrense taletiden hos teammedlemmene.

New Call-to-action


Eric jobber som senior manager i vår Digital-avdeling, og har lang erfaring i å lede utviklings- og implementeringsprosjekter på tvers av ulike bransjer. Han har tidligere jobbet som rådgiver ved Miljøverndepartementet, senior IT-rådgiver ved Oslo Kommune plan- og bygningsetaten, Senior prosjektleder ved Atea og Crayon, samt sist IT-Leder/Senior prosjektleder ved Capgemini Norge. Eric har en lidenskap for teknologi og innovative løsninger som utfordrer virksomheten. Han motiveres av utvikling og få til forbedring igjennom teknologi og digitalisering. Eric er Cand.Scient fra Universitetet i Oslo og er i tillegg utdannet siviløkonom ved Handelshøyskolen NMBU.


Likte du dette blogginnlegget? Da tror vi at disse også passer for deg

7 tips til å lykkes med bruk av flere rammeverk på en gang

Innen IT er det nå mange nyttige rammeverk som dekker hvordan vi kan organisere, forvalte, utvikle eller omstille vår virksomhet. Både teknologi, prosesser og organisasjon er omfattet. Hver standard har et verdifullt innhold, men det kan være utfordrende å se sammenhenger og grenseflater mellom dem. Særlig hvis du leder prosjekter eller omstillinger der for eksempel PRINCE2, MSP, MOP, PROSCI, TOGAF, ISO27001/2, IT4IT, ITIL4, SAFe, SCRUM, ITPP (for å nevne noen) eller flere er aktuelle å ta i bruk. Her gir vi deg 7 tips til hvordan du kan lede for å bruke rammeverkene på beste måte.

Hvorfor ønsker vi hyppige leveranser i smidige prosjekter?

Når vi gjennomfører prosjekter eller initiativer etter smidige metoder, ønsker vi å levere verdi underveis. Dette gjør man gjennom å levere gevinster gjennom prosjektets livssyklus i form av hyppige leveranser. Hyppige leveranser underveis er en av hovedhensiktene med å kjøre et prosjekt etter smidige prinsipper. I stedet for tradisjonelt å tenke på et prosjekt som et langt forløp som skal levere et sluttprodukt bør prosjektet planlegges som en serie av leveranser. I dette blogginnlegget gir vi deg syv gode grunner til å fokusere på hyppige leveranser.

Hva er Large Scale Scrum (LeSS)?

For dagens virksomheter er evnen til å tilpasse seg endringer raskt og effektivt avgjørende for suksess. Mens Scrum har nesten blitt en uunngåelig grunnmetode i digitaliseringsinitiativer, står store organisasjoner overfor utfordringer når de forsøker å skalere smidigheten til komplekse programmer. Large Scale Scrum (LeSS) har vokst frem som en prominent løsning for å møte disse utfordringene.