Planning Poker som estimeringsteknik

Planning Poker som estimeringsteknik Joakim Andersson, Christian Lindgren Lunds Tekniska Högskola, Lund, Sweden {ic06ja9, dt05cl5}@student.lth.se 2 mars 2010

Sammanfattning I den här rapporten så undersöks Planning Poker, en estimeringsprocess inom extreme Programming. Undersökningen utförs genom att testa tekniken på en grupp i en projektkurs inom XP. Slutsatser dras både om hur det fungerar att implementera tekniken samt hur effektiv den visar sig vara. i

Innehåll 1 Inledning 1 2 Bakgrund 1 2.1 Planning Poker............................. 1 2.2 Studien................................. 2 3 Tidigare studier 3 4 Metod 3 4.1 Iteration 1................................ 4 4.2 Iteration 2................................ 5 4.3 Iteration 3................................ 5 4.4 Iteration 4................................ 6 4.5 Iteration 5................................ 6 4.6 Iteration 6................................ 7 4.7 Grafik.................................. 7 5 Resultat 8 5.1 Fördelar................................. 9 5.2 Nackdelar................................ 9 5.3 Möjligheter............................... 9 5.4 Hot................................... 10 6 Slutsats 10 ii

1 Inledning När vi själva gjorde det XP-baserade projektet i grundkursen Programvaruutveckling i grupp (härmed kallat PvG ) kändes estimeringsprocesserna aldrig speciellt strukturerade, utan bestod i princip helt och hållet av gissningsarbete. När vi nu skulle vara coacher i ett utvecklarteam som utför samma projekt, ville vi se om, och i så fall hur, en mer strukturerad och strikt estimeringsprocess förbättrade estimeringarna. Därför tänkte vi jämföra den vanliga, s.k. ad-hoc -metoden (att mer eller mindre ostrukturerat jämföra storyn som ska estimeras med tidigare stories) med en metod som kallas för Planning Poker. Planning Poker passar bra in i XP:s Planning Game, eftersom det är just ett spel. Projektdeltagarna spelar i princip kort om hur stories ska estimeras, och då i förhållande till varandra. Det finns en del tidigare studier gällande Planning Poker, men ingen av dem är gjorda på projekt i PvG-projektets något mindre storlek. Studien har fokuserat på planering av iterationer. Release-planering har inte tagits upp, eftersom den planeringen ligger mer på kunden än utvecklarna. Vi börjar med att beskriva Planning Poker mer ingående i avsnitt 2. Därefter går vi igenom några resultat från tidigare studier i ämnet i avsnitt 3, för att sedan gå igenom och analysera vår statistik från studie i avsnitt 4. Till sist analyserar vi metoden som sådan med en s.k. SWOT-analys (Strengths, Weaknesses, Opportunities and Threats) i avsnitt 5 och avslutar med våra slutsatser i avsnitt 6. 2 Bakgrund 2.1 Planning Poker Konceptet Planning Poker beskrivs ganska väl i Mike Cohns bok Agile Estimating and Planning [Coh05]. Cohn anser själv att Planning Poker är den bästa estimeringsmetod han hittat för agila utvecklarteam. De främsta fördelarna han nämner är det faktum att alla utvecklare får säga sitt och bidra till estimeringarna. Metoden beskrevs första gången 2002 av James Grenning [Gre02]. Reglerna för Planning Poker, så som vi använde dem, lyder som följer: Förberedelser Alla utvecklare får en uppsättning kort med siffror. Våra uppsättningar med kort hade värdena 0, 1 2, 1, 2, 3, 5, 8, 13, 20, 40, 100. Förutom detta fanns även specialkorten, som i princip ska tolkas som att storyn måste delas upp, och?, som ska användas när man inte har någon aning om hur given story ska estimeras. De stories som ska estimeras jämförs för att få fram den story utvecklarna tycker är näst lättast. Denna story får direkt värdet 1 och används som bas för resten 1

av estimeringarna. En story som man tycker är fem gånger svårare än bas-storyn ska således få värdet 5. Anledningen till att man väljer den näst lättaste itstället för den lättaste misstänker vi beror på att man vill få estimaten att hålla sig på en någorlunda låg nivå och inte skjuta i höjden fort. Spelomgång 1. Någon presenterar en story som ska estimeras, och beskriver denna lite kort. Utvecklarna får möjlighet att ställa frågor om oklarheter. 2. Varje utvecklare väljer ett estimat bland sina kort, och lägger detta med framsidan nedåt framför sig. 3. När alla utvecklare lagt fram sina estimat, vänder alla sina kort samtidigt. 4. Om man sorterar korten i ordning och det saknas något värde i stegen som bildas (t.ex. om 3 och 8 ligger på bordet, men ingen 5 finns), ska de som estimerat låga värden och de som estimerat höga värden diskutera varför de estimerat som de gjort. Därefter går man tillbaka till steg 1. 5. När en korrekt stege kan bildas, vinner det högsta värdet på bordet. Gå igenom dessa steg för varje story som ska estimeras. Vi insåg dock först efter vi genomfört studien, att vi tolkat de regler vi fått för Planning Poker lite fel. I steg 4 ska det egentligen vara så att det inte får finnas mer än två olika värden på bordet, och de får inte vara mer än ett steg från varandra. [Coh05] Detta är ett ganska grovt misstag, men då vi upptäckte det för sent, var vi tvugna att förbise det. Dessutom anser vi, nu i efterhand, att de riktiga reglerna skulle ha gjort estimeringprocessen för lång för att hinnas med under våra tidsbegränsade planeringsmöten (á 2 timmar). 2.2 Studien Vår studie utfördes i ett studentprojekt baserat på XP-metoden. Utvecklarna i vårt team läste alla PvG-kursen, och vi författare hade rollen som coacher (genom kursen Coaching av programvaurteam ). Vår grupp bestod av åtta utvecklare och två coacher. Vår roll som coacher i teamet bestod i att leda teamet genom projektet för att de i slutändan förhoppningsvis skulle kunna arbeta mer självständigt. Vi coacher hade dessutom, som nämnt tidigare, gjort mer eller mindre exakt samma projekt ett år tidigare, och hade alltså viss erfarenhet i vad utvecklarna hade framför sig. Projektet var uppdelat på sex iterationer om en vecka vardera, med ett planeringsmöte (á 2 timmar), 4 timmars individuell spike-tid samt en långlabb, där den faktiska programmeringen ägde rum (á 8 timmar) per iteration. Studien har inte kunnat inkludera alla dessa iterationer, eftersom studien slutfördes innan projektet var klart. Kunden i 2

projektet var en lärare, som trots mer än god programmeringsvana agerade något datorovan och lät teamet fatta alla tekniska beslut. 3 Tidigare studier Nils Christian Haugen gjorde 2006 en studie av Planning Poker, där han lät ett utvecklarteam som var halvvägs in i ett projekt byta från ad-hoc till Planning Poker, för att därefter jämföra hur bra estimaten blev med de olika metoderna [Hau06]. Haugen ansåg här att Planning Poker kan förbättra estimaten, åtminstone jämfört med en mer ostrukturerad metod (ad-hoc). Han kom dock även fram till att Planning Poker kan försämra estimaten i de fall då gruppen inte estimerat några liknande stories, något som faktiskt kan appliceras på stora delar av vårt projekt. Slutligen kom Haugen fram till något som även vi märkt, att de extrema estimaten tenderar att bli ännu mer extrema vid användning av Planning Poker. Haugen gjorde även 2007, tillsammans med Kjetil Moløkken-Østvold, en studie där de kombinerade den klassiska metoden Expert Opinion med Planning Poker [MØH07]. I denna studie delade man upp alla stories slumpmässigt och lät hälften gå igenom Planning Poker och hälften helt och hållet utgå från expertutlåtandet. Här kom man fram till att Planning Poker kunde minska optimismen bland utvecklare jämfört med att kombinera individuella estimat på annat sätt. Man kom också fram till att resultaten från Planning Poker i vissa fall kan stämma bättre än ad-hoc. Shigeru Sasao gjorde 2009 enkel studie av Planning Poker, ad-hoc och en tredje metod kallad Paired Comparison [Sas09]. Innan vår studie påbörjades undersökte vi lite hur Paired Comparison fungerade, men kom fram till att den var alldeles för tekniskt avancerad för ett så litet projekt som vårt. Sasao baserade sin studie på studenter som skulle estimera storleken på några olika datastrukturer i antal rader kod. Det som främst testades här var hur mycket de olika estimaten skiljde sig mellan olika estimerare, och inte hur bra de stämde överens med verkligheten. Ur Sasaos resultat kan man dock läsa att Planning Poker i de flesta fall gav mer lika resultat än ad-hoc, även om Paired Comparison i de flesta fall gav ännu bättre resultat. 4 Metod Vid omvandlingen av poäng till tid har vi förutsatt ett linjärt förhållande. Det krävs ett flertal variabler för att göra tidsapproximationen. n par = Antalet par T = Effektiv arbetstid under en iteration a = Antalet poäng som antas bli avklarade under iterationen x story = Uppestimerade poäng för en specifik story y story = Approximerad tidsåtgång för en specifik story 3

Ekvationen som sedan används ser ut som följer. y iteration = n par T a iteration x iteration Variabeln a tas lämpligen fram med metoden Yesterday s weather (d.v.s. jämföra med hur mycket man klarade föregående iteration och ta ungefär lika mycket i nästa iteration), medan de andra variablerna är mer givna. För att kunna analysera estimeringsprocessens effektivitet beräknar vi skillnaden, t, mellan den estimerade cirkatiden och den faktiska tidsåtgången. Utifrån den uträknade tidsskillnaden finns det två sätt för att enkelt analysera estimeringarna. Det första är att helt enkelt rita upp ett låddiagram över tidsskillnaderna och på så sätt avgöra ifall estimaten är optimistiska eller pessimistiska, samt spridningen. Det optimala är att lådan är så liten som möjligt och ligger symmetriskt över x-axeln. Det andra sättet att analysera estimaten på kräver lite matematisk bearbetning. Det bygger helt enkelt på att slopa tecknet framför tidsskillnaden, för att koncentrera sig på hur långt ifrån nollan estimaten ligger, och sedan beräkna ett medelvärde. X = Avklarade stories n X = Antal stories i X y = Jämförelsetal y = story X t story n X Ett optimalt jämförelsetal är så lågt som möjligt, vilket betyder att staplarna i stapeldiagrammet bör vara nära noll för att tekniken ska vara effektiv. Genom att studera de två graferna kan vi avgöra hur estimeringsprocesserna skiljer sig åt samt hur bra tekniken är. 4.1 Iteration 1 I denna första iteration fick vi som coacher lägga ner ganska mycket tid på att beskriva alla stories och vad de faktiskt gick ut på. Detta kan liknas vid Haugen och Moløkken-Østvolds studie av Planning Poker och Expert Opinions [MØH07], även om vi försökte att hålla oss undan från att ge faktiska förslag på estimat. 4

Story/Task Poäng Estimerad circatid Faktisk tid t Klar 3.1 1 19min 1h 5min + 46min Ja 3.2 5 1h 36min 4h 15min + 2h 39min Ja 3.3 8 2h 34min 2h - 34min Ja 3.4 8 2h 34min 1h 50min - 44min Ja 3.5 13 4h 10min 2h 20min - 1h 50 min Ja 4 13 4h 10min 2h 5min - 2h 5min Ja 5 5 1h 36min 1h 40min + 4min Ja 6 20 6h 24min 2h 40min + Nej 7 20 6h 24min 5h 20 min - 1h 4min Ja 8 20 6h 24min 1h 15min - 5h 9min Ja y = 99,44 min 4.2 Iteration 2 Story/Task Poäng Estimerad circatid Faktisk tid t Klar 9 5 3h 5min 6h 40min+ Nej 10 2 1h 14min 2h 5min+ Nej 11 8 4h 55min 1h 27min - 3h 28min Ja 12 8 4h 55min 1h 25min - 3h 30min Ja 14 3 1h 51min 1h 31min - 10min Ja 17 5 3h 5min 2h 35min+ Nej 18 8 4h 55min 2h 10min - 2h 45 min Ja Release 8 4h 55 min 4h 3min - 52min Ja y = 129,0 min 4.3 Iteration 3 I iteration 3 lät vi ett annat team, som i iteration 1 och 2 använt sig av ad-hoc-metoden för sina estimeringar, testa Planning Poker. Detta försök föll dock inte så väl ut, då teamet efter hälften av de stories de skulle estimera återgick till ad-hoc. Motiveringen till detta var främst att deras estimat blev mycket högre när de använde Planning Poker, och att de helt enkelt trivdes bättre med den vanliga ad-hoc-metoden. Story/Task Poäng Estimerad circatid Faktisk tid t Klar 9 20 7h 7min 8h 50min + 1h 43min Ja 10 5 1h 47min 30min - 1h 17min Ja 13 8 2h 51min 4h 35min+ Nej 19 40 14h 13min 3h 30min+ Nej 25 13 4h 37min 2h 55min - 1h 42min Ja y = 94,0 min 5

4.4 Iteration 4 Inför iteration 4 bestämde vi oss för att förändra reglerna något. Detta främst då vi märkt att det väldigt lätt blev en inflation i poäng med de (feltolkade) reglerna. Denna inflation i poäng medförde oftast att basestimatet låg långt ifrån restrerande estimat. Därför valde vi att, istället för att välja den näst lättaste storyn som basestimat och ge denna värdet 1, välja en story i mitten och ge denna en 2:a. För att vidare göra det svårare för enskilda personer att höja estimatet, och därmed förhindra inflationen, valde vi att välja det högsta värdet i tredje kvartilen istället för det högsta värdet av alla som vinnande estimat. I vårt team på åtta utvecklare innebar det alltså att välja det tredje högsta värdet. Dessutom noterade vi att våra originalregler inte sade någonting om hur?-kort skulle hanteras. Vi valde därför att sätta en gräns på max två stycken sådana kort på bordet för att ett estimat skulle gå igenom. I idealfallet vill man visserligen egentligen inte ha några frågor kvar i teamet när man går vidare till nästa story, men vi såg ingen direkt felanvändning av dessa kort i vårt team. Därför ansåg vi att det är bättre att låta några stå över estimeringen än att låta grupptrycket få dem att säga något de inte helt kan stå för. Story/Task Poäng Estimerad circatid Faktisk tid t Klar 13 2 2h 55min 6h 55min + 4h Ja 18, 19, 23 10 1 14h 32min 9h 45min+ Nej 26 3 4h 22min 3h 10min - 1h 12min Ja y = 156,0 min 4.5 Iteration 5 Story/Task Poäng Estimerad circatid Faktisk tid t Klar 15, 16, 21 5 6h 16min 3h 5min+ Nej 18 1 1h 15min 4h 15min + 3h Ja 19, 23 8 10h 2min 5h 45min - 4h 17min Ja 27 2 2h 31min 40min -1h 51min Ja 1 29 2 38min 3h 35min + 2h 57min Ja 30 3 3h 46min 2h 55min+ Nej 31 4 2 5h 1min 1h 30min - 3h 31min Ja 32 2 2h 31min 1h 10min - 1h 21min Ja 1 Resultat av sammanslagningen av stories 2 En kompromiss mellan 3 och 5 y = 169,5 min 6

4.6 Iteration 6 Story/Task Poäng Estimerad circatid Faktisk tid t Klar 15, 16, 21 5 7h 16min 5h+ Nej 20 2 2h 55min 2h 40min - 15min Ja 22 2 2h 55min 2h 20min+ Nej 30 5 7h 16min 3h 37min - 3h 39min Ja y = 117,0 min 4.7 Grafik Figur 1: Låddiagram över t-värdena Låddiagrammet i figur 1 visar information om hur spridda våra t-värden är för de olika iterationerna. Lådorna ringar in den mittersta hälften av materialet, och det röda strecket i varje låda betecknar medianen. Strecken utanför lådorna visar maximumoch minimumvärden, och slutligen betecknas extremvärden (som inte riktigt verkar följa resten av datan), även kallade uteliggare som röda plustecken. Det går att se i diagrammet att våra resultat från de första tre iterationerna, borträknat extremvärdena, visar att våra estimat i regel är något pessimistiska, men att merparten 7

ändå håller sig hyfsat samlade strax runt nollpunkten. Däremot kan det se ut som att vår nya metod orsakade sämre estimat, men på grund av det låga antalet färdiga stories i dessa iterationer kan man inte riktigt dra några slutsatser på samma sätt. Figur 2: Våra y-värden Däremot kan man i figur 2 se att jämförelsevärdena för de tre första iterationerna ligger lägre än de för de tre sista, och visar därför att de tre första iterationerna hade något bättre estimat. I och med att dessa värden utgår från medelvärden, till skillnad från låddiagrammet, beror de inte till lika stor del på antalet stories, vilket gör att mätvärdena går att jämföra mellan metoderna. Det enda som därför skulle kunna förkasta denna hypotes skulle i så fall vara dåligt statistiskt underlag. 5 Resultat För att göra en heltäckande genomgång av resultaten har vi valt att dela upp resultatet i samma struktur som en SWOT-analys. SWOT är indelat i fördelar (strengths), nackdelar (weaknesses), möjligheter (opportunities) och hot (threats). Där varje rubrik analyseras en i taget. Värt att notera är att vi i resultatet utgår ifrån de felaktiga spelregler vi använt oss av 8

under projektets gång och därmed följer också andra nackdelar och svagheter än vad som skulle uppdagas med originalreglerna. 5.1 Fördelar Fördelarna med Planning Poker som estimeringsteknik ligger främst i dess förmåga att skapa struktur i, och snabba upp estimeringsprocessen. Det är även därför tekniken tagists fram. [Gre02] Som mycket annat för även Planning Poker med sig fler fördelar än vad som var tänkt vid införandet. De fördelar som vi sett hittills är alla kommer till tals, något som även Cohn [Coh05] noterat i sin bok. Att gruppen dessutom ser estimeringsprocessen som en lek skapar en mer avslappnad och lätthanterlig situation. 5.2 Nackdelar De nackdelar som vi erfarit handlar i stort sett om problemet med att avgöra när estimeringensprocessen är över. I och med att det räckte med endast ett stegs skillnad mellan varje estimat, för att godkänna det högsta, så var det lätt hänt att en överestimering gick igenom. När väl denna överestimering gått igenom började de efterföljande estimaten influeras av överestimatet. Att poängskalan är exponentiellt utformad gjorde situationen bara värre då en inflation startade. En annan stor nackdel i detta fall var att diskussionsdelen helt kunde gå förlorad trots stor skillnad i estimat. Detta, och merparten av föregående, problem berodde dock främst på att vi feltolkat reglerna. Att diskussionen helt kan försvinna var i och för sig en av grundidéerna med Planning Poker [Gre02], men då bara när teamet är helt överens. Ett av de största problemen vi hade, oberoende av reglerna, var dock att poängskalan inte var konsekvent över iterationerna, vilket i princip påtvingar omestimering vid varje iteration och försvårar kundens prissättning. Detta kan man lösa genom att utgå från tidigare estimeringar, men i vårt fall, på grund av inflationen i poäng, hade detta inte gått. 5.3 Möjligheter Den sak som vi tror skulle förbättra Planning Poker som estimeringsteknik sett från de svagheter som uppdagats är att förändra själva skalan. En linjär skala hade känts mer naturlig. Förutom skalan skulle det verka mer rimligt att estimera i timmar samt välja ett rimligare värde när en godkänd mängd estimat sållats fram. Att iterera hela estimeringsförfarandet två gånger känns även det som en god idé. På så sätt går det att se estimaten i en slags helhet innan estimaten spikas. 9

5.4 Hot Det som kan göra det svårt att införa Planning Poker är inlärningsperioden som krävs. Det krävs ett antal iterationer innan tekniken sitter. En annan sak som kan skapa problem är att kunden kan motsätta sig tekniken, något som faktiskt hände oss. I de fall estimaten blir dåliga kan kunden tycka att tekniken är oseriös, men detta är förvisso ett följdproblem av det förstnämnda problemet. 6 Slutsats Enligt våra resultat har Planning Poker en del fördelar, men metoden är ganska tidskrävande, och passar därför inte in i mindre projekt, i stil med PvG-projektet. Däremot kan metoden passa bra in på större projekt, där planeringstiden inte är lika begränsad som i vårt projekt. Våra något felaktiga regler (och de förändringar vi införde) kan dock ses som en anpassning för denna tidsbegränsning, och för utvecklarnas ringa erfarenhetsnivå. Vårt något begränsade test att införa Planning Poker i ett utvecklarteam som fått viss tid att vänja sig vid ad-hoc slog också mindre väl ut. Av detta test kan vi dock dra slutsatsen att Planning Poker, åtminstone initialt (och med våra regler), kan ge felaktiga estimat i en grupp som är van vid ad-hoc. Haugens studie [Hau06] tyder ju dock på att resultatet borde ha blivit bättre oavsett. De förändrade regler vi införde i Iteration 4 undanröjde några av de direkta nackdelarna vi hittat, och vi såg efter detta att utvecklarna i större utsträckning höll sig på samma nivå i sina privata estimat. Detta kan ses som ett steg på vägen mot de korrekta reglerna, men tidsproblemet kvarstår. Dock visade det ju sig att våra nya regler faktiskt gav aningen sämre estimat. Detta kan i och för sig bero på andra faktorer som t.ex. gruppens dynamik och programkodens komplexitet. Allt som allt vill vi avsluta med att estimeringsmetoden troligen inte orsakar några större skillnader i ett så pass nedskalat projekt som vårt. Detta beror både på att tiderna är så korta och att våra stories så små. Detta medför att fel i estimeringar ger större utslag i statistiken här än i riktiga agila projekt. En stor orsak till detta är att administrativa uppgifter, som t.ex. att markera stories som färdigimplementerade eller att läsa igenom stories, utgör en större procentuell andel av den totala tiden. 10

Referenser [Coh05] M. Cohn. Agile estimating and planning. Prentice Hall PTR, 2005. [Gre02] J. Grenning. Planning Poker or How to avoid analysis paralysis while release planning. 2002. [Hau06] NC Haugen. An empirical study of using planning poker for user story estimation. I: Agile Conference, 2006, s 9, 2006. [MØH07] K. Moløkken-Østvold och NC Haugen. Combining Estimates with Planning Poker An Empirical Study. I: Software Engineering Conference, 2007. ASWEC 2007. 18th Australian, ss 349 358, 2007. [Sas09] S. Sasao. Paired Comparison: A User Perspective. I: 24th International Forum on COCOMO and Systems/Software Cost Modeling, CSSE, 2009. 11