En praktisk studie i estimeringstekniker inom extreme Programming EDA270. Fredrik Åkerberg Tommy Kvant March 5, 2013

Relevanta dokument
Studie av estimeringstekniker för Extreme Programming. F. Stål D08, Lunds Tekniska Högskola

Planning Poker som estimeringsteknik

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Scrum + XP samt konsekvensanalys

TDP023 Projekt: Agil systemutveckling

TDDD26 Individuell projektrapport

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth.

SCRUM. Marcus Bendtsen Institutionen för datavetenskap

12 principer of agile practice (rörlig)

SCRUM och agil utveckling

Agil programutveckling

Inspel till dagens diskussioner

SCRUM och mycket mer

Nyttomaximering av spikes

Proj-Iteration 5B. Plan för återstående iterationer

Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola

SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Reflektion i Agila Projekt Djupstudie

Proj-Iteration1. Arkitektur alt. 1

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare

Video tutorials som undervisningsverktyg, win-win för lärare och studenter

Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA

Gruppdynamik och gruppsykologi i Extremet Programming

Planeringsspelets mysterier, del 1

Att effektivt strukturera, utföra och utvärdera spikes

Eventuella kommentarer: Under kursens gång har 4 studenter hoppat av utbildningen.

BESKRIVNING AV PROCESSMETODEN SCRUM

Enkätresultat. Kursenkät, Flervariabelanalys. Datum: :47:04. Aktiverade deltagare (MMGF20, V10, Flervariabelanalys) Grupp:

F6 Arkitektur, Planering

Proj-Iteration 3. Grov plan för releaser

XP-projekt: En fördjupning

En studie om parprogrammering i praktiken

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Mätning av fokallängd hos okänd lins

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

Vad tycker Du om oss?

Djupstudie - Datorbaserade system för tracking

34% 34% 13.5% 68% 13.5% 2.35% 95% 2.35% 0.15% 99.7% 0.15% -3 SD -2 SD -1 SD M +1 SD +2 SD +3 SD

Självorganiserande team och coachens anpassade roll

Att skriva sin rapport. Jan Thim

Piteås kunskapsresultat jämfört med Sveriges kommuner 2015/2016

Forskningsmetoder i offentlig förvaltning

Kritik av Extrem Programmering

PD104A - Introduktion för Produktuteckling och design

Sammanfattning... Fel! Bokmärket är inte definierat. Kommunens mål hur har det gått?... 1

TDDD39-Perspektiv på informationsteknologi

Beskrivande statistik

2 Dataanalys och beskrivande statistik

BIOSTATISTISK GRUNDKURS, MASB11 ÖVNING 6 ( ) OCH INFÖR ÖVNING 7 ( )

IMPLEMENTERING AV VIARY FÖR PULSEN, halvdag för hela gruppen

TATA24-Linjär Algebra

Konsultarbete, Hitta maximal volym fo r en la da

Vad gör att en kurs uppfattas som engagerande och intressant?

Samsynsinspektioner. Utbyte av kunskap och erfarenheter för ökad samsyn

Agila Metoder. Nils Ehrenberg

Statistiska begrepp och uttrycksformer

Del I: Digitala verktyg är inte tillåtna. Endast svar krävs. Skriv dina svar direkt i provhäftet.

RAPPORT: SÅ TYCKER SVERIGES HR-CHEFER OM MEDARBETARUNDERSÖKNINGAR

KLEINLEKTION. Område statistik. Lektionens upplägg. Lämplig inom kurserna Matematik 2b och 2c. Engage (Väck intresse) Explore (Upptäck laborera)

Stora talens lag eller det jämnar ut sig

Övningsprov 3 inför lilla nationella Ma1 NA18 ht18

SCRUM på Riksarkivet. Magnus Welander /

TDP023 Projekt: Agil systemutveckling

Vägledning för genomförande av

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT Lars Larsson Algoritmer 1

Bilagor Projektrapport VoteIT år 1

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

W W W. A N T S. S E E R S T A G A T A N 1 C , S T O C K H O L M

9A Ma: Statistik och Sannolikhetslära

Laboration 2. i 5B1512, Grundkurs i matematisk statistik för ekonomer

FACIT (korrekta svar i röd fetstil)

Uppdrag för LEGO projektet Hitta en vattensamling på Mars

Rune Tennesmed. Oskar Norling 1DV430. Individuellt Mjukvaruutvecklingsprojekt 1DV430 Webbprogrammerare H12 Oskar Norling

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE

THFR41 - Teknisk kommunikation på franska del II

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB

Användarcentrerad systemdesign

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker

OBS! Vi har nya rutiner.

Sidor i boken f(x) = a x 2 +b x+c

Hur, när och till vad använder personer sin smarta telefon eller surfplatta? Personers medievanor på mobila enheter.

Arbetsrapport CEQ, ETS170

MEDARBETARSAMTAL SAMTALSGUIDE

2 Praktisk information om intervjuerna

INSTRUKTIONER OCH TIPS Fördjupningsarbete Receptarier (15 hp) och Apotekare (30 hp)

Utvärdera din kommunikation

Information via diagram inom ett XP-team

Pavel Denisov D01, Lunds Tekniska Högskola 21:e februari 2006

inte följa någon enkel eller fiffig princip, vad man nu skulle mena med det. All right, men

Absolut möjligt. Problemet. per-eskil persson

Torun Berlind Elin Önstorp Sandra Gustavsson Klas Nordberg. Föreläsningar Lektioner Laborationer Projekt

Effektiviteten i Försäkringskassans ärendehantering

Tentamen i Statistik, STA A10 och STA A13 (9 poäng) Fredag 8 december 2006, Kl

Projekt i programmering 1 (ver 2)... 2 Projektidé... 2 Planering... 2 Genomförande... 2 Testning och buggar... 3 Utvärdering... 3 Planering...

MVE051/MSG Föreläsning 7

Business research methods, Bryman & Bell 2007

Sammanställning av Kursvärdering för VFU Normal motorik och sjukgymnastisk undersökning (3SG075)

Transkript:

En praktisk studie i estimeringstekniker inom extreme Programming EDA270 Fredrik Åkerberg Tommy Kvant March 5, 2013

Contents 1 Introduktion 1 2 Bakgrund 2 2.1 Tracker programmet......................... 2 2.2 Estimeringstekniker......................... 2 2.2.1 UGE.............................. 2 2.2.2 Statistical........................... 3 2.2.3 Planning Poker........................ 3 3 Tidigare Studier 4 4 Metod 4 4.1 UGE.................................. 5 4.2 Statistical............................... 5 4.3 Planning Poker............................ 5 5 Resultat 6 5.1 Data från våra Iterationer...................... 6 5.2 Sammanställning av Iterationerna................. 9 5.3 Jämförelse av estimeringsteknikerna................ 9 6 Diskussion 11 6.1 Analys av Estimeringsfel....................... 11 6.2 Felkällor................................ 12 6.3 Framtida studier........................... 13 7 Sammanfattning 13 I

Abstract Denna studien kommer behandla frågorna: vilken estimeringsteknik är bäst utifrån storleken på estimeringsfelet, samt vilken estimeringsteknik ger minst estimeringsfel med minst tid spenderad på estimering? De estimeringstekniker som kommer att jämföras är UGE, Statistical och Planning Poker. Studien utfördes under sex iterationer på ett team bestående av studenter i kursen Programvaruutveckling i grupp på LTH. Slutsatserna av denna studien var att Planning Poker var det som gav bäst resultat utifrån båda frågeställningarna. Det finns dock en risk då omfånget av studien är rät begränsad. Men även om resultaten inte är helt slutgiltiga så kan de ligga till grund för fortsatta studier. II

1 Introduktion I ett projekt är det viktigt att kunna skatta hur lång tid projektet kommer att ta. Både för att en eventuell köpare ska veta när produkten eller delar av produkten kan vara klar och även för att projektgruppen ska kunna uppskatta ett tidsvärde på produkten som kunden ska betala. Detta medför att korrekt estimering av projektet och dess delar är viktigt både för kunden och projektgruppen. Generellt sett så kan man också tänka sig att själva estimeringsmomentet i dig är ganska vitalt för hur nöjd kunden blir. Eftersom om man estimerar man alltid för högt så kommer troligtvis kunden känna sig lurad och inte riktigt lita på teamets framtida estimeringar. Om man istället alltid underestimerar, så kommer kunden troligtvis bli besviken på det som finns med i releaser. Därav är det eftersträvansvärt att försöka hitta ett sätt för att alltid lyckas minimera felet i estimeringarna. Det som kan förorsaka dåliga estimeringar är till att börja med dåliga tekniker, som t.ex. att man höftar fram estimeringar utan att basera det på något. Andra saker kan vara att informationen om det som ska estimeras är bristfällig, eller att de som ska estimera är oerfarna. Ytterliggare saker kan vara tidspress vilket kan leda till att estimeringen stressas fram. Annat kan vara ineffektiva diskussioner, som leder till att alla aspekter inte tas upp eller att kärnan i estimeringen försvinner. När vi läste PVGn, så gick estimeringen oftast ganska dåligt och drog ut på tiden. Troligvis för att båda våra team använde UGE (se avsnitt 2.2.1), som är en ostrukturerad estimeringsteknik. Båda våra team använde också en tracker där vi skrev upp hur lång tid stories:arna verkligen tog, dock användes dessa tider inte för att ge feedback, utan coacherna slängde dessa i slutet av långlabben. Vi reagerade inte på detta och en av anledningarna till detta, kan vara att vi som team-medlemmar inte insåg nyttan i att använda denna data. Det är dock lite märkligt att coacherna inte använde det heller, då dessa borde inse ovanstående problematik. Ovanstående ledde i sin tur till att när vi valde att läsa coachingkursen, kom vi ganska snabbt fram till att det var estimeringar vi vill ha som djupstudie. Då vi båda hade ganska dålig erfarenhet av just detta moment. När vi sen funderade lite till så kom vi framtill att vi ville jämföra olika estimeringstekniker, dels den intuitiva tekniken(uge) som vi hade använt när vi läste PVGn, och dels två andra lite mer strukturerade former av estimeringstekniker. Vi bestämde oss för att dessa två skulle vara Statistical och Planning Poker. Dessa är s.k. informella estimeringstekniker som förlitar sig på personlig erfarenhet istället för dokumenterad erfarenhet. Till skillnad från informella estimera så kräver formella estimeringar att det dels finns mkt data att jämföra med, samt att någon efterhand fyller på denna databas. Vilket i sin tur medför att unga företag och nya projekttyper inte kan använda sig av detta [5]. Man har dock kommit framtill att den formella inte nödvändigtvis ger bättre resultat än den informella [5]. 1

Problemställningen vi har valt är att i första hand jämföra estimeringsteknikerna utifrån estimeringsfelet. Men vi har även gjort en jämförelse baserad på hur mycket tid estimeringstekniken tar i jämförelse med hur exakt estimeringen blir. Vilket i sin tur användes för att kunna avgöra vilken estimeringsteknik som har maximal exakthet med minimal estimeringstid. 2 Bakgrund Vår studie utfördes på tre stycken team i kursen Programvaruutveckling i Grupp (EDA260) [8]. Denna kursen är en projektkurs där eleverna är medlemmar i ett team, som ska utveckla ett program för att kunna beräkna tider för Enduro tävlingar. Kursen försöker simulera hur det är att utveckla mjukvara i en större grupp. Teamet jobbar agilt under 6 stycken iterationer, genom att använda XP. Till sin hjälp har teamen coacher under hela utvecklingsskedet. Coacherna för de olika teamen kommer ifrån en annan kurs som heter Coachning av programmeringsteam (EDA270) [9]. Estimeringen i XP utförs under Planning Game, som är ett slags planeringsmöte. Vid detta mötet närvara hela teamet och kunden. Teamet utför estimering av de Stories som kunden vill ha, varpå kunden sätter en prioritering på dessa, vilket utformar planeringen av nästkommande iteration.[10] 2.1 Tracker programmet För att underlätta vårt arbete när det gäller att samla in data från projektet, så utvecklade vi ett program som fungerade som vår tracker. Denna har funktioner för att checka-in och checka-ut stories, som startar resp. stannar tidtagningen för den specifika storyn, och därefter spara detta i ett exceldokument. När man lägger till en story så anger man hur mycket man har estimerat den till. Programmet visar både den estimerade tiden och den tiden man har spenderat på varje story sida vid sida. På så sätt så är det lätt att hålla koll på hur arbetet går per story i jämförelse med vad man estimerat. 2

2.2 Estimeringstekniker I vår undersökning så använde vi oss av tre olika estimeringsmetoder: UGE, Statistical och Planning Poker. Vissa har ibland ändrats lite från sin definition för att bättre passa arbetssättet i PVG-projektet. Hur vi anpassar dessa kan man läsa om under metod. Eftersom projektet pågår under 6 veckor så använde vi varje estimeringsteknik vid två tillfällen var. Vår förhoppning var att kanske kunna eliminera faktorn över de deltagande elevernas vana att estimera. Så vi tog och använde estimeringsteknikerna i följande sekvens: UGE Statistical planning poker UGE Statistical planning poker. Under respektive vecka. 2.2.1 UGE För att få en grund i vår jämförelse mellan estimeringstekniker så har vi valt att ta med den teknik som vi anser är den mest grundläggande och intuitiva. Som helt enkelt innebär att sitta ner och diskutera fram en estimering. Härefter kommer vi att hänvisa till det som UGE(Unstructured Group Estimation)[1]. Den är inte svårare än vad den låter, de deltagande sitter ner och diskuterar storyn, de som känner att de har något att säga om i frågan delger de andra vad de tycker. 2.2.2 Statistical Här bestäms estimeringen endast genom att individuella estimeringar slås samman genom att man antingen räknar ut genomsnittet eller medianen. Det förekommer inte någon annan interaktion mellan de som deltager i estimeringen, utan de estimerar varje story för sig själv.[4] 3

2.2.3 Planning Poker I Planning Poker börjar man med att alla deltagare får var sin uppsättning kort, antingen med förtryckta estimeringar eller blanka där man får skriva själv. Storyn läses sedan upp och diskuteras lätt för att alla ska få klarhet i den. Sedan väljer var och en ut för sig själv, utan att visa de andra, den estimering de tror på. Alla vänder sedan sina kort och visar sina estimeringar. Om alla är överens så behövs ingen mer diskussion utan man tar den estimeringen man kommit fram till. Ifall man inte är överens så får man diskutera mer. Man fokuserar mycket på extrempunkterna, dvs. de som har valt de högsta respektive lägsta estimeringarna. Detta för att de andra ska få veta varför de har tagit just de "extrema" värdena. Efter den diskussionen gör man om proceduren och estimerar igen. Och så fortsätter men så tills man når en överenskommelse.[2] Genom att utföra denna proceduren så blir Planning Poker en kompromiss där man skyddar oberoendet mellan estimerarna samtidigt som man tillåter diskussion ansikte mot ansikte. Det kan argumenteras för att detta gör så Planning Poker tar del av fördelar från båda sidor. Däribland att alla estimeringar presenteras samtidigt och blir därigenom inte påverkas av varandra och framförallt av de mest dominanta personerna i gruppen, därigenom kan varje åsikt bli hörd. Även eftersom man fokuserar på att diskutera de högsta och lägsta estimeringarna så finns det möjlighet till att hitta många problem som kan påverka implementeringen. [6] 3 Tidigare Studier I Armstrongs artikel[7], menar de att diskussioner ansikte mot ansikte, så som i Planning Poker och UGE, har en negativ påverkan på estimeringarna och att estimeringar gjorda med statistiska metoder var mer exakta. Detta stöds av resultaten i Mahnics artikel[6], där de kom fram till att individuella estimeringar gjorda av studenter var mindre optimistiska än de gjorda med Planning Poker och att statistiskt sammanställda individuella estimeringar var mer exakta. De kom dock fram till att estimeringar via Planning Poker gjorda med experter tvärt om var mindre pessimistiska och mer exakta än estimeringar gjorda via statistisk kombination av individuella estimeringar. Men att denna skillnad var väldigt liten och de inte kunde bekräfta det utan att göra fler studier. För vår del så är deltagarna i PVG-kusen inte experter utan studenter, så vad vi borde kunna förvänta oss utifrån dessa tidigare studier är att den statistiska metoden kommer ge ett mer exakt resultat än de gjorda med Planning Poker. I Haugens artikel[1], där man jämförde Planning Poker och UGE, så kom man fram till att estimeringarna från Planning Poker var mer exakta när man estimerade tasks som man var bekant med. Däremot när man estimerade tasks som man inte var bekant med så ökade felen när man estimerade med Planning Poker jämfört med UGE. Med tanke på detta så borde vi få se att exaktheten hos våra tidiga estimeringar inte är så hög, men att de blir allt mer exakta allt eftersom. 4

4 Metod För varje iteration kommer vi att visa ett diagram över hur mycket varje story estimerades jämfört med hur lång tid de verkligen tog. Endast de stories som är färdiga tas med i diagrammen. Det kommer även att finnas en tabell med värden i diagrammet tillsammans med hur effektiv estimeringen var. Vi definierar effektiviteten med BRE(balanced messure of relative error).[6] Och de definieras enigt följande: BRE = actual effort estimated effort min(actual effort, estimated effort) Förut, i tidigare studier, har man använt magnitude of relative error (MRE = actual effort estimated effort /actual effort) för att beräkna effektiviteten av estimeringar. Den visar effektiviteten som felet mellan den verkliga tiden och den estimerade i procent av den verkliga tiden. Men efter att ha fått skarp kritik från flera forskare så har bland annat [6] valt att använda BRE istället. Fördelen med BRE är att det ger en mer jämn balansering mellan överestimering och underestimering, till skillnad från M RE. Då BRE visar samma skillnad i procent fast av den minsta av den verkliga och den estimerade tiden. För att få en bild över huruvida teamen blir bättre på att estimera eller ej, så har vi tagit hjälp av två andra team som kör samma estimeringsteknik under samtliga iteration. För att jämföra de olika estimerings teknikerna mot varandra, där vi tar hänsyn till hur lång tid det tar att estimera varje story. Så har vi använt följande formel F elminuter = BRE Estimeringstid #Stories Formeln består av två delar. Den första delen är BRE:n för estimeringstekniken. Och den andra delen är tiden det tog att estimera ett antal stories dividerat med antalet stories. Det ger oss tiden det tar att estimera en story med sagda estimeringteknik. Genom att multiplicera dessa ger det oss ett värde för en estimeringsteknik som beror på både tiden det tar att estimera en story med estimeringstekniken och effektiviteten för estimeringstekniken. Med denna formel så kommer värdet av den att öka om tiden för att estimera en story ökar samt att värdet kommer öka om effektiviteten minskar(dvs. BRE ökar). Det samma gäller då att om någon av faktorerna minskar så minskar värdet för formeln. 4.1 UGE Vi genomförde denna genom att först diskutera, vad den storyn som skulle estimeras innebar. Därefter höll vi en diskussion där teamet fick diskutera vad de trodde skulle bli problem och tillslut tillsammans komma fram till ett värde som blev det värdet vi använde på den storyn. 4.2 Statistical Här lät vi teamet tillsammans, likt ovan, diskutera varje story, fast utan att komma fram till något värde. Därefter så fick de individuellt och anonymt skriva 5

ner sina estimeringar på varje story. När detta var klart sammanställde vi dessa och räknade ut medelvärdet. Vi valde att använda medelvärdet eftersom det är det som rekommenderas för att sammanställa estimeringar. [3] Medelvärdet blev i sin tur det värdet som vi satte på storyn. 4.3 Planning Poker I Planning Poker så estimerar man om flera gånger tills man når en överenskommelse. Detta har potential till att dra ut på tiden ganska rejält och tiden för planeringsmötena är mycket begränsad och mycket ska hinnas med. Så vi fick göra en kompromiss och valde att först alla fick göra en estimering och att vi diskuterade den utifrån extremvärdena. Sedan gjorde vi en andra estimering och tog medelvärdet från den estimeringen. Detta bör ge ett resultat som pekar åt det som skulle kommits fram till genom flera om-estimeringar utan att dra ut på proceduren. Eftersom deltagarna redan diskuterat estimeringarna, i alla fall en gång, så bör de redan ha påverkat varandra att dra åt något håll och estimeringarna bör konvergera. 5 Resultat Vi har delat upp resultatet i tre delar. Den första innehåller detaljerade stapeldiagram över estimeringarna och den reella tiden för varje story för varje iteration för vårt team. Nästa del innehåller jämförelser mot andra team. Dessa är iterationsbaserade och innehåller diffarna och BRE:n. Den sista delen innehåller jämförelser mellan de olika estimeringsteknikerna. 5.1 Data från våra Iterationer 6

7

8

5.2 Sammanställning av Iterationerna 9

5.3 Jämförelse av estimeringsteknikerna Den första grafen visar medelfelet för varje teknik, dvs. medelvärdet av BRE:n för de två tillfällena för respektive teknik. Den andra visar felets kostnad i minuter per story för varje estimeringsteknik. Den sista visar skillnaden i det absoluta felet mellan första och andra tillfället för varje estimeringsteknik. 10

6 Diskussion Denna sektion har vi valt att dela in i tre delar. Den första delen behandlar vilken estimeringsteknik som är bäst, baserat på hur stor avvikelse från estimering de har i jämförelse med varandra. Den andra delen behandlar vilken estimeringsteknik som är bäst, baserat på hur stor avvikelse viktat med tiden för estimering i jämförelse med varandra. Den tredje behandlar de felkällor som kan ha påverkat vår studie och den sista delen behandlar eventuella fortsatta studier. 11

6.1 Analys av Estimeringsfel Utifrån figur Medelfelet för varje teknik i avsnitt 5.3 så ser man tydligt att Planning Poker är den mest exakta estimeringstekniken som vi använde. Man ser också att UGE:n ger störst fel, detta är inte jättekonstigt då denna är den teknik som är mest partisk. Detta eftersom det blir de personer i teamet som låter mest eller har högst social status som avgör i vilken riktning som estimeringarna kommer att gå. Denna partiskhet existerar inte alls i Statistical då estimeringarna är anonyma. Detta syns även i figuren då den nästan ger ett halverat fel i förhållande till UGE. Statistical är som sagt anonymt, men tappar därav en potentiellt givande diskussion. Detta löses i Planning Poker, som har lite anonymitet men mer diskussion, vilket enligt figuren verkar ge bättre resultat. Vilket i sin tur skulle kunna påvisa att Planning Poker drar fördelar från både UGE och Statistical. Figur Medelfelet för varje teknik i avsnitt 5.3 tar dock inte hänsyn till hur lång tid själva estimeringen tar utan enbart effektiviteten hos tekniken. Som nämnts tidigare så kan man tänka sig ett fall där det tar mycket tid att få fram en estimeringen, men estimeringen är väldigt exakt. Detta kan som även nämnts ovan ge en skev bild av vilken teknik som verkligen är effektivast. Därför har vi även valt att titta på hur effektiviteten viktat med tiden ser ut, detta visas i figur Felets kostnad i minuter per story i avsnitt 5.3. Här ser man att Statistical börjar ta in på Planning Pokers ledning, dock så är den fortfarande sämre. Så även UGE vars förhållande till Planning Poker inte nämnvärt har ändrats. Utifrån tidigare studier, så kom vi fram till, att för vårt team så borde vi ha fått ett resultat där Statistical gav en mer exakt estimering, än de andra teknikerna. Detta var dock inte fallet, som man kan se i figur Medelfelet för varje teknik i avsnitt 5.3. Detta skulle kunna bero på att vår studie är baserad på en för kort tid. Detta skulle kunna ses i figur Diffar för de olika teknikerna i avsnitt 5.3, där det ser ut som om Statistical har potential att kunna stagnera runt en lägre nivå. Detta leder till att man skulle kunna dra slutsatsen att vårt team estimerar likt experter, men eftersom studiens omfattning är av denna omfattning, så är denna slutsats troligtvis missvisande. Om man anstränger sig, så skulle man se liknande tendenser, som de som beskrivs i Haugens artikel[1] och har nämnts ovan. Dock hävdar vi att det är en alldeles för liten omfattning på vår studie, för att kunna dra några definitiva slutsatser rörande sagda påståenden. 6.2 Felkällor En studie som denna, är benägen att påverkas av datafel. Förutom de felkällor vi redan har nämnt, så har vi några till som vi har upptäckt. En av de potentiellt största felkällorna är att team-medlemmarna, inte alltid sa till oss när de började eller avslutade en story. Detta ledde till att vi inte registrerade allt helt korrekt med hur de egentligen spenderade tiden. Det var mer märkbart allt eftersom tiden gick. De var mer noggranna med det i början, men mot slutet blev de slarvigare. Detta borde inte ge ett så stort utslag då det totala arbetet 12

oftast kom med i statistiken ändå, fast på fel task. Dock så finns det tillfällen som t.ex. på morgonen och efter lunch där vi i vissa fall inte startade arbetet förrän en bit in. En uppenbar felkälla är att utförandet av vår studie gör det svårt att mäta hur vida vårt team blir bättre på att estimera med tiden. Så har vi tagit in två andra teams resultat av respektive estimering och lagt in dessa i en graf över BRE och en graf över diffar(absolutfelet) se figur BRE respektive figur Diffar i avsnitt 5.2. Utifrån dessa kan vi dock inte dra slutsatsen att teamen skulle bli bättre på att estimera. På vissa ställen ser det ut som att där finns en trend som pekar åt att de skulle bli bättre. Men värdena varierar på vissa ställen för mycket för att man ska kunna dra några definitiva slutsatser hur vida de blir bättre eller inte. Däremot är det intressant att vårt teams estimeringar ligger så pass bra till i jämförelse med de andra teamen. Vad detta beror på kan vi endast spekulera i. En annan felkälla är att estimeringen per story inte speglas i det jämförande resultatet, utan det är bara de totala tiderna för varje iteration som jämförs. Det verkar som att vi alltid har haft estimeringar, som både varit under resp. över estimerade i varje iteration. Vilket har lett till at detta felet inte har påverkat resultatet i slut änden. En annan relevant felkälla är att Planning Poker kördes under iteration 3 och 6, vilket kan ha lett till att teamet var bättre på att estimera under dessa i förhållande till de andra. Vilket i sin tur kan ha lett till att resultatet för Planning Poker blev bättre än det skulle ha varit. Den sista felkällan som vi har valt att ta med som en relevant felkälla är de andra teamens data, då det har kommit till vår kännedom att dessa kanske inte alltid har varit helt ackurata. 6.3 Framtida studier Vi märkte under iterationernas gång att vårat program, som vi använde för att mäta tider, hjälpe oss att lätt hålla koll på vem som gjorde vad. Och att på så sätt fick vi en bra överblick över arbetet. Det gjorde också att vi på ett exakt sätt kunde räkna ut hur mycket tid teamet arbetade effektivt varje iteration. Detta kunde vi sen använda som riktlinje för teamet nästkommande iteration så att de visste hur mycket tid de kunde räkna med att hinna med den iterationen. På så sätt kan det ha bidragit till att vi fick bra estimeringar, då vi fick bra återkoppling. Om man tittar på figur Diffar för olika tekniker i avsnitt 5.3 så kan man se att både UGE och Statistical har en dramatisk förbättring i avvikelse från deras estimerade tider. Till skillnad från Planning Poker som verka hålla sig hyfsat jämnt på samma nivå. En möjlig idé till ett framtida projekt är att låta det gå fler iterationer och se hur dessa värden utvecklar sig efter en längre tid. Om de alla kommer konvergera mot noll eller inte. Alternativt att UGE och Statistical närmar sig exaktheten av Planning Poker. För att komma fram till mer konkreta resultat så borde denna studien utökas till fler iterationer. Men även att man använder sig av, minst, tre team där varje 13

team kör sin egen estimeringsteknik under en längre tid. Då borde man kunna se ett tydligare mönster och få tydligare resultat och kanske kunna bekräfta det som resultaten av denna studie antyder på. 7 Sammanfattning I denna studien kom vi fram till, utifrån förhållandena för hur vi lade upp iterationerna, att Planning Poker är överlägset bäst om man bara är intresserad av att få så bra estimeringar som möjligt. Planning Poker är enligt våra resultat också den bästa om man viktar med tidsfaktorn det tar att estimera med den. Dock så har Statistical en potential om man ökar antalet iterationer. Så resultatet från studien är inte helt slutgiltiga, men de skulle ligga till grund för framtida studier, möjligtvis av framtida coacher. 14

References [1] N.C. Haugen: An empirical study of using planning poker for user story estimation, Agile Conference, 2006. [2] J. Grenning: Planning Poker or How to avoid analysis paralysis while release planning, 2002. [3] M. Jørgensen: A review of studies on expert estimation of software development effort, Journal of Systems and Software, 2004. [4] K. Moløkken-Østvold, N.C. Haugen, H. C. Benestad: Using planning poker for combining expert estimates in software projects, Journal of Systems and Software, 2008. [5] K. Moløkken-Østvold, M. Jørgensen: Group processes in software effort estimation, Empirical Software Engineering, 2004. [6] V. Mahnic, T. Hovelja: On using planning poker for estimating user stories, Journal of Systems and Software, 2012. [7] J. S. Armstrong: How to make better forecasts and decisions: avoid face-toface meetings, The International Journal of Applied Forecasting, 2006. [8] http://cs.lth.se/eda260/ [9] http://fileadmin.cs.lth.se/cs/education/eda270/ [10] http://en.wikipedia.org/wiki/extreme_programming_practices 15