Upræcise estimater er blandt de mest populære udfordringer inden for projektledelse. Når man starter et nyt IT-projekt, vil man gerne vide to ting: hvor lang tid det vil tage, og hvor meget det vil koste. For at besvare disse spørgsmål skal du estimere de projekter, du skal i gang med. Der er ingen magisk regel, der siger, at projekt X tager 12 uger og koster $150.000. Eller at et Y-lignende website tager 10 uger at udvikle og koster $100.000.
Hvad du vil lære af denne artikel:
- Hvordan forbereder projektledere sig på omkostningsestimering i projektledelse?
- Hvilke estimeringsteknikker er nyttige til projektevaluering?
- Hvad kræver det at forberede sig på at estimere omkostninger med formler?
Du kan ikke vurdere et projekts tidslinje eller omkostninger uden en grundig estimering, heller ikke selvom projektets omfang minder meget om det, du har lavet før. Men det bliver værre endnu: Estimering vil aldrig give dig et 100% præcist svar på disse spørgsmål. Så hvorfor estimerer vi? Fordi det er den eneste måde at lave antagelser om projektets tidslinje og budget, arbejdsbyrden og de ressourcer, der er nødvendige for at levere det.
Når du estimerer projektet, er du også i stand til at planlægge medarbejdere med den rette erfaring og de rette færdigheder. Det, du kan gøre ved det, er at bruge metoder og teknikker, der giver dig mulighed for at estimere med størst mulig nøjagtighed. Her kan du se, hvordan du bruger Agile-metoden og Planning Poker-teknikken til at skabe meningsfulde estimater af dit projekt.
James Grenning udviklede den planlægningspokersession, der er kendt for sin strategi, i 2002 kaldet Scrum-poker. I begyndelsen af 1950'erne var hans estimeringsmetode, Wide band Delphi, for tidskrævende og havde andre begrænsninger. I Grennings tilfælde handlede pokerplanen oprindeligt om at løse et problem, hvor spillerne var for begejstrede og overfokuserede til at vinde. Mike Cohn, grundlægger af Agile alliancer og Scrum-alliancer, brugte senere denne teknik i en artikel med titlen Agile Estimation and Planning.
At starte et vellykket projekt afhænger først og fremmest af, hvor godt du forstår, hvad det egentlig handler om. Det inkluderer:
- Forstå din kundes forventninger
- Forståelse af projektets mål og hovedformål
- Oprettelse af en liste over nødvendige funktioner
Når du har gennemgået kundens briefing og har så mange oplysninger om projektets krav som muligt, kan du liste alle funktionerne og sende dem videre til dit team.
For at gøre det skal du oprette en produktbacklog, der består af alle to-do-funktioner. Derefter kan du prioritere dem, vurdere deres kompleksitet og estimere, hvor lang tid det vil tage at færdiggøre dem. En ordentlig produktbacklog bør bestå af:
- Brugerhistorier - beskriver de handlinger, som brugerne kan udføre på hvert trin i brugen af produktet
- Acceptkriterier - en liste over de ting, der skal til, for at en historie er færdig.
- Story points - estimer mængden af arbejde, risici og kompleksitet i relativ pointværdi
- Opgaver til brugerhistorier - liste over de opgaver, der skal udføres for at levere en brugerhistorie
Det er afgørende at involvere udviklingsteamet i at skabe og prioritere produktbackloggen for at sikre nøjagtige og realistiske vurderinger.
Når du har en liste over funktioner klar, skal du prioritere hver enkelt af dem. Du kan bruge MoSCoW-analysemetoden til at sortere dem som:
- Skal have
- Burde have
- Kunne have
- Vil ikke have
Når du udvikler et projekt, skal du fokusere på de ting, du skal levere i første omgang. At bygge en MVP giver dig mulighed for at teste hypoteser om din idé, før du færdiggør hele projektet, vise den til interessenter eller beta-brugere og indsamle feedback, der er vigtig for den videre udvikling af resten af funktionerne.
Prioritering kan også hjælpe dig med at estimere projektet. Når du fokuserer på de vigtigste funktioner og dem, du skal lave først, kan du komme med mere præcise antagelser om deres forventede færdiggørelse. For "kunne have"-funktioner kan du starte med et skøn, da de er længere fremme i udviklingsprocessen, og meget kan nå at ændre sig, inden dit team når frem til dem (og hvis dit team når frem til dem, da du efter at have indsamlet feedback om din MVP kan ændre dig og ikke inkludere alle de oprindeligt planlagte funktioner).
Det er dog vigtigt at estimere alle funktioner, uanset deres prioritet (undtagen dem, man ikke vil have, selvfølgelig), da man ønsker at få et overblik over hele projektet på én gang. Og når du kommer til de næste faser af projektet, kan du revurdere arbejdets omfang for at sikre, at dine estimater forbliver nøjagtige.
Nu, hvor du har færdiggjort din produktbacklog, er det tid til at estimere hver enkelt af dens elementer. Til det formål bruger vi story points. Det er enheder, som agile teams bruger til at evaluere det arbejde, der skal til for at færdiggøre hvert element i backloggen. Story points hjælper med at tildele relativ værdi til emnerne på produktbackloggen. De er ikke relateret til tid og kan have forskellig værdi for forskellige teams, så de har ikke nogen følelsesmæssig værdi. Derfor er der gode chancer for, at teammedlemmerne ikke udvider estimaterne bare for at være på den sikre side. Planning Poker hjælper softwareteams med at planlægge arbejdsgange og forbedre projektets leveringshastighed.
Ved hjælp af story points kan et team estimere:
Planning Session er en af estimeringsteknikkerne på bruttoniveau, der bruger en modificeret version af Fibonacci-sekvensen: 1, 2, 3, 5, 8, 13, 20, 40, 100. For at estimere emner fra produktbackloggen får teammedlemmerne de samme sæt planlægningspokerkort med tal på. Efter en kort introduktion af produktbackloggen af Product Owner (som ikke stemmer) og diskussionen, vælger de privat kortet med det antal story points, som de anser for at være relevante for den mængde arbejde, der kræves for at færdiggøre dette punkt, og afslører dem på samme tid.
Hvis tallene er forskellige, diskuterer teammedlemmerne, hvorfor de har valgt et bestemt antal story points, og stemmer derefter igen. Dette er en del af planlægningspokerprocessen, en konsensusbaseret estimeringsmetode, der bruges i Agile til at estimere indsatsen for brugerhistorier. Det gør de, indtil de når til enighed, og så går de videre til det næste punkt fra produktbackloggen. Og hvis det antal, der opnås enighed om, er højt, lad os sige 20, 40 eller højere, betyder det, at en historie måske kræver for meget arbejde til et sprint og skal deles op i mindre opgaver. Ideelt set bør præsentationen af emnet, diskussionen og afstemningen tage omkring to minutter, hvilket gør det muligt at estimere hele backloggen på kort tid. Men da pointen her er at estimere hele backloggen på én gang, skal du tage dig god tid og ikke bekymre dig, hvis nogle historier tager lidt længere tid at vurdere.
Team-hastighed viser dig, hvor hurtigt projektet udvikler sig. Det hjælper med at forstå to ting:
- Hvor meget arbejde dit team er i stand til at udføre i et sprint
- Hvad er den forventede dato for færdiggørelse af hele omfanget, forudsat at det er løst
Hastigheden er forskellig for hvert team. Du kan vurdere den efter de første iterationer, når dit team allerede har arbejdet på nogle funktioner. Hvis du f.eks. har inkluderet fire product backlog-elementer i den første iteration med et samlet antal på 20 story points, og teamet har færdiggjort tre af dem svarende til 15 story points, så er det teamets aktuelle hastighed. Husk, at kun afsluttede punkter tæller. Selv hvis det er lykkedes at starte det fjerde punkt, men ikke har afsluttet det, tæller det ikke med.
Scrum-masteren spiller en afgørende rolle i at facilitere estimeringsprocessen og sikre nøjagtige vurderinger under disse sessioner.
Når du har forhandlet story points og vurderet teamets hastighed, kan du bestemme projektets tidsplan. Det gør du ved at lægge teamets hastighed fra de sidste tre iterationer sammen og dividere den med tre. Hvis hastigheden fra disse iterationer f.eks. var 20, 23 og 17, ville den gennemsnitlige hastighed svare til ca. 20 point. Hvis den samlede mængde arbejde var blevet estimeret til 100 story points, ville det med en gennemsnitshastighed på 20 point tage 5 iterationer at færdiggøre projektet. Hvis vi antager, at en iteration tager to uger, skal du levere projektet på 10 uger.
For at bestemme budgettet for dit projekt kan du bruge denne grundlæggende formel: (samlede Story Points / hastighed * teamtimer pr. sprint) + ikke-lønomkostninger = estimeret budget. Når du har det samlede antal story points divideret med den gennemsnitlige hastighed, skal du gange antallet af sprints med 40 timer pr. uge pr. teammedlem for at få dine lønomkostninger. Tilføj derefter de ikke-arbejdsmæssige omkostninger som kapitalomkostninger, udstyrsomkostninger, vedligeholdelsesomkostninger, uddannelsesomkostninger osv. For eksempel har vi et projekt, der er estimeret til 100 story points, og vores teams gennemsnitshastighed er 20. Hvis vi tildeler et team på 5 personer til projektet med en timepris på $50, er teamets timer pr. sprint $20.000 og $100.000 værd for 5 sprints. Med en hypotetisk ikke-arbejdsmæssig omkostning på $50.000 vil det anslåede budget for vores projekt være $150.000. I betragtning af konfidensintervallerne på eksemplariske niveauer på 80-120% er det rapporterede interval for vores budget nu $120.000 til $180.000.
Husk, at ingen estimering er 100% præcis. Det er bedst at estimere dit projekt igen med nogle få iterationer, da ting som ressourcetilgængelighed, teamets hastighed eller projektets omfang kan ændre sig over tid. Når du estimerer igen, sørger du for, at dit estimat er opdateret. Brug af software til tidsregistrering og ressourceplanlægning vil også hjælpe dig med at styre dit teams tilgængelighed og omfordele dem, hvis det er nødvendigt. Med de rigtige teknikker og værktøjer kan du gøre dine estimater mere pålidelige og bedre planlægge dit næste projekt.
Præcise projektestimater er afgørende for en vellykket projektledelse. Ved at forstå forventningerne og målene, skabe en detaljeret produktbacklog, prioritere funktioner og bruge teknikker som story points og Planning Poker kan du forbedre nøjagtigheden af dine estimater. Regelmæssig reestimering og brug af værktøjer til tidssporing og ressourcestyring øger pålideligheden af projektets tidslinjer og budgetter yderligere. Ved at følge disse fremgangsmåder kan du overvinde udfordringerne ved unøjagtige estimater og sikre bedre projektresultater.
Brug Planning Poker-estimeringsteknikken med lethed
Se, hvorfor vores ressourcestyringssoftware er valgt af projektledere fra Hill-Knowlton eller Stormind Games.
Ressourcekalenderen (eller projektstyringskalenderen, projektplanlægningskalenderen, ressourceplanlægningssoftwaren) giver dig mulighed for at planlægge, styre og fordele ressourcer mere effektivt - især hvis Microsoft Excel har spillet en hovedrolle i din...
Hvad er det ultimative mål for projektledere? At levere deres projekter med succes. PM'erne indrømmer selv, at det ikke sker særlig ofte: Ifølge den seneste Pulse of the Profession-undersøgelse bliver mindre end 60% af projekterne afsluttet enten...
Kapacitetsstyring er en strategi, som virksomheder bruger til at udnytte produktionseffektiviteten bedst muligt i forhold til efterspørgslen på en service eller et produkt. Det endelige mål med kapacitetsstyring er at: Identificere og...