Planning poker

For at kunne planlægge indhold, skal man kende omfang - og det gælder også for scrum, selvom om iterationerne er så korte, så man kan holde ud at sprinte igennem dem. Et af de foretrukne værktøjer til at anslå omfang af opgaver, når man bruger scrum som metode, er planning poker.

Det er der efter min mening en række gode grunde til:

• der er gode chancer for at få vendt alle relevante sten ("none of us is as smart as all of us")
• fremgangsmåden er lightweight - input er en "story" som kompakt beskrives et ønske, og så de fakta, som deltagerne spørger ind til, for at kunne danne sig en mening.
• vurderingen sker af dem, som skal udføre opgaven.
• der satses på konsensus.
• indbygget i metoden er hensyntagen usikkerheden stiger med resultatets størrelse.
  

Men der er også en række fælder:

Sammenfaldende interesser?

I det agile manifest slår man fast, at man foretrækker samarbejde med kunden fremfor kontraktforhandlinger (er jeg den eneste, som hæfter mig ved, at ordet kollaboration, som jo både på dansk og engelsk kan betyde samarbejde med fjenden, står lige ved siden af ordet kunde i manifestet?). Vi tror mao. på, at vi har fælles interesser, og så virker metoden da også bedst.

Men har vi fælles interesser? Product owner har jo en interesse i, at få så meget som muligt lavet, og er han menneske som os andre, så vil han nemt kunne fristes til at underspille omfanget af opgaven, for derved at få teamet til at love mere end det ellers ville. Tilsvarende vil et team, som tidligere er blevet udsat for opgaver, som har vist sig at være mere komplicerede end antaget under planlægningen, begynde at indregne risikotillæg i deres vurderinger.

Specielt kritisk bliver det, hvis man bruger vurderingsmetoden i et fastpris scenarie (og derfor mener jeg at man skal være meget forsigtig med at blande de to...), men effekten vil allerede opstå, hvor der ikke er fælles ejerskab af vurderingen ... hvis product owner efterfølgende kan slippe afsted med at sige "Jamen team, I lovede..." eller endnu værre, hvis teamets performance alene bliver målt på dets evne til at opfylde vurderingerne.

Diskussionen er specielt relevant, når man estimerer i fysiske tidsenheder (det være sig såvel kalender- eller, mere typisk, mande-dage), og et forslag har derfor været at estimere i story points i stedet - story point er meget lig function points i deres tilgang, i det at begge forsøger at estimere kompleksitet uden også at estimere effektivitet. Der findes også også argumenter imod at bruge storypoints.

Manglende konsensus

En stor fordel ved metoden er, at alle bliver hørt, og at der er enighed om vurderingen. Hvis det da er tilfældet...

For det er dels vigtigt, at hele teamet deltager i vurderingen, hvis hele teamet senere skal kunne forventes at bakke op om resultatet. En planning poker seance er med andre ord et glimrende tidspunkt til at skille pigs fra chickens - hvis der er nogen i teamet, som mener sig ude at stand til at deltage, så er der stor chance for, at de i virkeligheden er kyllinger i grise-kostumer....

Den anden fælde er, at man stopper diskussionen inden der er konsensus. Det er dræbende for det fælles fodslag, hvis deltagerne sidder tilbage med følelsen af "nu blev det godt nok 5 dage, men jeg tror nu mere på 8 dage...!"

For meget konsensus (eller af de forkerte årsager) kan nu også være af det onde.

Ovendreven tro på nøjagtigheden

I virkeligheden, så kan man jo skrive denne advarsel om stort set hvad som helst - at være sig begrænsninger bevidst er jo altid en god ting. Metoden har allerede indbygget en stillingtagen til usikkerheden i den kraftige progression, som der findes i kortenes talrække. Når man læser beskrivelsen hos ophavsmanden, så er det tydeligt, at han forventer at resultatet er en af disse diskrete værdier (man stopper ikke førend der er konsensus om en af disse).

Et alternativ, som jeg har set praktiseret, er at stoppe når spredningen er kommet under et vist niveau (vores tommelfingerregel er maks. tre på hinanden følgende diskrete værdier), og så tage et passende gennemsnit. Fordelen er, at man ikke bruger langt til på at få de sidste decimaler diskuteret på plads (det flytter næppe meget, og det kan tage lang tid), men ulempen er dels, at man kan opnå en distance til resultatet, og dels, at resultatet præsenteres med en nøjagtighed som det ikke kan bære.

Et eksempel: Vores regel vil acceptere flg. stemmer:

8, 13, 13, 20, 20, 20,

og det naive resultat vil være 15,7 dage (eller måske mere reelt 15 2/3). Dels signalerer decimalerne times nøjagtigt i noget , hvor inputtet var mere end hele dage (der er en uge mellem 8 og 13 dage, og længere imellem 13 og 20 dage), dels ligger det omkring 4 dage under halvdelen af gætterne!

En anden vinkel på det er, at hvis bare en enkelt havde taget et kort, som lå lige ved siden af, så ville det kunne flytte gennemsnittet en dag i hver retning. Et mere reelt resultat havde altså været godt tre uger, eller omkring 16 dage. Har man brug for at kende resultatet mere præcist, så har man enten specificeret storien for grovkornet, eller også er man i gang med at detajlplanlægge.

En godt checkpoint er at spørge alle deltagerne, om de vil kunne acceptere resultatet (igen med specielt fokus på dem, som lægger længst væk). Hvis man gør der, og en af de folk som har vendt f.eks. "20" i virkeligheden vaklede imellem det og så "40", så vil det komme frem!

Hvad snakker vi om?

Når man vurderer på et så uformelt grundlag, som en story og diskussion med udgangspunkt i nogle afklarende spørgsmål, så er det vigtigt at man er enige om, hvad det er, at man vurderer.

Den første fælde er, at de forskellige deltagere i diskussionen løb har dannet sig et forskelligt billede af, hvad løsningen går ud på. Der har sikkert været en livlig diskussion af alternativer og afgrænsninger, og hvis ikke der gøres et grundigt arbejde af moderator med sikre fælles fodslag dels i hovederne på deltagerne og dels som forudsætning for vurderingens validitet efterfølgende, så risikerer man nemt at få svar på noget andet end det, som man spørger om.

Tilsvarende er det vigtigt, at man er enige om, at man kun vurderer gruppens egen indsats. Hvis det er en forudsætning at andre end teamet bidrager, så er det netop en forudsætning - disse andre må selv komme med deres eget bud på, hvad deres del vil andrage, hvis der er relevant. At bede teamet om også at tage dette med, er at tage dem som gidsler på noget, som de dels ikke har forudsætninger for, og dels næppe vil kunne føle ansvar for efterfølgende.

Det stiller også krav om, at teamet består af generalizing specialists - hvis der er for stort spænd i kompetancerne (f.eks. fordi at der er flere, som ikke kan programmere, og opgaverne indeholder betydelige programmeringselementer), så kan det betyde, at vurderingen bliver rent gætværk, simpelthen fordi at folk mangler forudsætningerne for at mene noget fornuftigt. Alternativet med, at lade dele af teamet erklære sig inhabile, er heller ikke godt, dels af hensyn til det fælles ejerskab, dels fordi at man så risikerer at miste et vigtigt input. Under alle omstændigheder, så er det at have et team af generalizing specialists identificeret som en af de afgørende faktorer for at have højt ydende team, så hvis situationen opstår, så skal man overveje om teamet er korrekt sammensat.

Er det så ikke bare noget bras?

Jeg kan ikke fortænke noget, hvis de nu sidder og spørger sig selv, om metoden er noget bras? I så fald, så læs lige om fordelene i indledningen igen - det er et glimrende værktøj, men man skal være sig dets begrænsninger bevist.

Personligt mener jeg, at der er det bedste værktøj til vurdering af opgaver inden sprintplanlægning i et velfungerede scrumteam. Det forudsætter dog stor modenhed fra alle parter - både fra teamet og fra dets omgivende interessenter.

(Opdateret 3. nov. 2007: Der er kommet en fortsættelse med titlen Mere om Planning Poker)