{"id":2825,"date":"2024-07-01T12:03:26","date_gmt":"2024-07-01T10:03:26","guid":{"rendered":"https:\/\/teamdeck.io\/?p=2825"},"modified":"2025-01-23T22:46:57","modified_gmt":"2025-01-23T20:46:57","slug":"how-to-estimate-projects","status":"publish","type":"post","link":"https:\/\/teamdeck.io\/da\/projektledelse\/hvordan-man-estimerer-projekter\/","title":{"rendered":"Planning Poker Estimation Technique og Story Points"},"content":{"rendered":"
\n\t
\n\t\t
\n\t\t\t

Udfordringen ved un\u00f8jagtige estimater<\/h3>\n

Upr\u00e6cise estimater er blandt de mest popul\u00e6re udfordringer inden for projektledelse. N\u00e5r 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\u00f8rgsm\u00e5l 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.<\/p>\n

N\u00f8glesp\u00f8rgsm\u00e5l besvaret i denne artikel<\/h3>\n

Hvad du vil l\u00e6re af denne artikel:<\/p>\n

- Hvordan forbereder projektledere sig p\u00e5 omkostningsestimering i projektledelse?<\/p>\n

- Hvilke estimeringsteknikker er nyttige til projektevaluering?<\/p>\n

- Hvad kr\u00e6ver det at forberede sig p\u00e5 at estimere omkostninger med formler?<\/p>\n

\"\"<\/figure>\n

Vigtigheden af n\u00f8jagtig estimering<\/h3>\n

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\u00f8r. Men det bliver v\u00e6rre endnu: Estimering vil aldrig give dig et 100% pr\u00e6cist svar p\u00e5 disse sp\u00f8rgsm\u00e5l. S\u00e5 hvorfor estimerer vi? Fordi det er den eneste m\u00e5de at lave antagelser om projektets tidslinje og budget, arbejdsbyrden og de ressourcer, der er n\u00f8dvendige for at levere det.<\/p>\n

\"\"<\/figure>\n

Fordele ved n\u00f8jagtig estimering<\/h3>\n

N\u00e5r du estimerer projektet, er du ogs\u00e5 i stand til at planl\u00e6gge medarbejdere med den rette erfaring og de rette f\u00e6rdigheder. Det, du kan g\u00f8re ved det, er at bruge metoder og teknikker, der giver dig mulighed for at estimere med st\u00f8rst mulig n\u00f8jagtighed. Her kan du se, hvordan du bruger Agile-metoden og Planning Poker-teknikken til at skabe meningsfulde estimater af dit projekt.<\/p>\n

\"\"<\/figure>\n

Oprindelsen til planl\u00e6gningspoker<\/h3>\n

Hvor kom Scrum (Planning) Poker fra?<\/h4>\n

James Grenning udviklede den planl\u00e6gningspokersession, der er kendt for sin strategi, i 2002 kaldet Scrum-poker. I begyndelsen af 1950'erne var hans estimeringsmetode, Wide band Delphi, for tidskr\u00e6vende og havde andre begr\u00e6nsninger. I Grennings tilf\u00e6lde handlede pokerplanen oprindeligt om at l\u00f8se et problem, hvor spillerne var for begejstrede og overfokuserede til at vinde. Mike Cohn, grundl\u00e6gger af Agile alliancer og Scrum-alliancer, brugte senere denne teknik i en artikel med titlen Agile Estimation and Planning.<\/p>\n

\"\"<\/figure>\n

Trin til n\u00f8jagtig projektestimering<\/h3>\n

Lav en liste over n\u00f8dvendige funktioner<\/h4>\n

At starte et vellykket projekt afh\u00e6nger f\u00f8rst og fremmest af, hvor godt du forst\u00e5r, hvad det egentlig handler om. Det inkluderer:<\/p>\n

- Forst\u00e5 din kundes forventninger<\/p>\n

- Forst\u00e5else af projektets m\u00e5l og hovedform\u00e5l<\/p>\n

- Oprettelse af en liste over n\u00f8dvendige funktioner<\/p>\n

N\u00e5r du har gennemg\u00e5et kundens briefing og har s\u00e5 mange oplysninger om projektets krav som muligt, kan du liste alle funktionerne og sende dem videre til dit team.<\/p>\n

Udvikling af en produktbacklog<\/h4>\n

For at g\u00f8re det skal du oprette en produktbacklog, der best\u00e5r af alle to-do-funktioner. Derefter kan du prioritere dem, vurdere deres kompleksitet og estimere, hvor lang tid det vil tage at f\u00e6rdigg\u00f8re dem. En ordentlig produktbacklog b\u00f8r best\u00e5 af:<\/p>\n

- Brugerhistorier - beskriver de handlinger, som brugerne kan udf\u00f8re p\u00e5 hvert trin i brugen af produktet<\/p>\n

- Acceptkriterier - en liste over de ting, der skal til, for at en historie er f\u00e6rdig.<\/p>\n

- Story points - estimer m\u00e6ngden af arbejde, risici og kompleksitet i relativ pointv\u00e6rdi<\/p>\n

- Opgaver til brugerhistorier - liste over de opgaver, der skal udf\u00f8res for at levere en brugerhistorie<\/p>\n

Det er afg\u00f8rende at involvere udviklingsteamet i at skabe og prioritere produktbackloggen for at sikre n\u00f8jagtige og realistiske vurderinger.<\/p>\n

Prioritering af funktioner<\/h3>\n

Sorter funktioner efter prioritet<\/h4>\n

N\u00e5r du har en liste over funktioner klar, skal du prioritere hver enkelt af dem. Du kan bruge MoSCoW-analysemetoden til at sortere dem som:<\/p>\n

- Skal have<\/p>\n

- Burde have<\/p>\n

- Kunne have<\/p>\n

- Vil ikke have<\/p>\n

N\u00e5r du udvikler et projekt, skal du fokusere p\u00e5 de ting, du skal levere i f\u00f8rste omgang. At bygge en MVP giver dig mulighed for at teste hypoteser om din id\u00e9, f\u00f8r du f\u00e6rdigg\u00f8r hele projektet, vise den til interessenter eller beta-brugere og indsamle feedback, der er vigtig for den videre udvikling af resten af funktionerne.<\/p>\n

Vigtigheden af at tildele prioritet<\/h4>\n

Prioritering kan ogs\u00e5 hj\u00e6lpe dig med at estimere projektet. N\u00e5r du fokuserer p\u00e5 de vigtigste funktioner og dem, du skal lave f\u00f8rst, kan du komme med mere pr\u00e6cise antagelser om deres forventede f\u00e6rdigg\u00f8relse. For \"kunne have\"-funktioner kan du starte med et sk\u00f8n, da de er l\u00e6ngere fremme i udviklingsprocessen, og meget kan n\u00e5 at \u00e6ndre sig, inden dit team n\u00e5r frem til dem (og hvis dit team n\u00e5r frem til dem, da du efter at have indsamlet feedback om din MVP kan \u00e6ndre dig og ikke inkludere alle de oprindeligt planlagte funktioner).<\/p>\n

Omfattende estimering<\/h4>\n

Det er dog vigtigt at estimere alle funktioner, uanset deres prioritet (undtagen dem, man ikke vil have, selvf\u00f8lgelig), da man \u00f8nsker at f\u00e5 et overblik over hele projektet p\u00e5 \u00e9n gang. Og n\u00e5r du kommer til de n\u00e6ste faser af projektet, kan du revurdere arbejdets omfang for at sikre, at dine estimater forbliver n\u00f8jagtige.<\/p>\n

\"\"<\/figure>\n

Estimeringsteknikker<\/h3>\n

Proces for estimering af historiepunkter<\/h4>\n

Nu, hvor du har f\u00e6rdiggjort din produktbacklog, er det tid til at estimere hver enkelt af dens elementer. Til det form\u00e5l bruger vi story points. Det er enheder, som agile teams bruger til at evaluere det arbejde, der skal til for at f\u00e6rdigg\u00f8re hvert element i backloggen. Story points hj\u00e6lper med at tildele relativ v\u00e6rdi til emnerne p\u00e5 produktbackloggen. De er ikke relateret til tid og kan have forskellig v\u00e6rdi for forskellige teams, s\u00e5 de har ikke nogen f\u00f8lelsesm\u00e6ssig v\u00e6rdi. Derfor er der gode chancer for, at teammedlemmerne ikke udvider estimaterne bare for at v\u00e6re p\u00e5 den sikre side. Planning Poker hj\u00e6lper softwareteams med at planl\u00e6gge arbejdsgange og forbedre projektets leveringshastighed.<\/p>\n

Ved hj\u00e6lp af story points kan et team estimere:<\/p>\n