{"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\/nb\/prosjektledelse\/hvordan-man-estimerer-prosjekter\/","title":{"rendered":"Estimeringsteknikk for planleggingspoker og Story Points"},"content":{"rendered":"
\n\t
\n\t\t
\n\t\t\t

Utfordringen med un\u00f8yaktige estimater<\/h3>\n

Un\u00f8yaktige estimater er en av de mest popul\u00e6re utfordringene innen prosjektledelse. N\u00e5r du starter et nytt IT-prosjekt, vil du vite to ting: hvor lang tid det kommer til \u00e5 ta, og hvor mye det kommer til \u00e5 koste. For \u00e5 kunne svare p\u00e5 disse sp\u00f8rsm\u00e5lene m\u00e5 du estimere prosjektene du skal kj\u00f8re. Det finnes ingen magisk regel som sier at prosjekt X tar 12 uker og koster $150 000. Eller at et Y-lignende nettsted tar 10 uker \u00e5 utvikle og koster $100 000.<\/p>\n

Viktige sp\u00f8rsm\u00e5l besvares i denne artikkelen<\/h3>\n

Hva du vil l\u00e6re av denne artikkelen:<\/p>\n

- Hvordan forbereder prosjektledere seg p\u00e5 kostnadsestimering i prosjektledelse?<\/p>\n

- Hvilke estimeringsteknikker er nyttige for prosjektestimering?<\/p>\n

- Hvordan forbereder du deg p\u00e5 \u00e5 estimere kostnader ved hjelp av formler?<\/p>\n

\"\"<\/figure>\n

Viktigheten av n\u00f8yaktig estimering<\/h3>\n

Du kan ikke vurdere et prosjekts tidslinje eller kostnader uten grundig estimering, selv om prosjektets omfang er sv\u00e6rt likt det du har gjort f\u00f8r. Og det blir enda verre: Estimering vil aldri gi deg et 100% n\u00f8yaktig svar p\u00e5 disse sp\u00f8rsm\u00e5lene ogs\u00e5. S\u00e5 hvorfor estimerer vi? Fordi det er den eneste m\u00e5ten \u00e5 gj\u00f8re antakelser om prosjektets tidslinje og budsjett, arbeidsmengden og ressursene som trengs for \u00e5 levere det.<\/p>\n

\"\"<\/figure>\n

Fordelene med n\u00f8yaktig estimering<\/h3>\n

N\u00e5r du estimerer prosjektet, kan du ogs\u00e5 planlegge ansatte med riktig erfaring og kompetanse. Det du kan gj\u00f8re, er \u00e5 bruke metoder og teknikker som lar deg estimere med st\u00f8rst mulig n\u00f8yaktighet. Slik bruker du Agile-metodikken og Planning Poker-teknikken til \u00e5 lage meningsfulle estimater for prosjektet ditt.<\/p>\n

\"\"<\/figure>\n

Opprinnelsen til planleggingspoker<\/h3>\n

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

James Grenning utviklet i 2002 en planleggingspoker\u00f8kt som er kjent for sin strategi kalt Scrum poker. P\u00e5 begynnelsen av 1950-tallet var estimeringsmetoden hans, Wide band Delphi, for tidkrevende og hadde andre begrensninger. I Grennings tilfelle handlet pokerplanen opprinnelig om \u00e5 l\u00f8se et problem der spillerne var for entusiastiske og overfokuserte til \u00e5 vinne. Mike Cohn, grunnleggeren av Agile allianser og Scrum-allianser, brukte senere denne teknikken i en artikkel med tittelen Agile Estimation and Planning.<\/p>\n

\"\"<\/figure>\n

Trinn til n\u00f8yaktig prosjektestimering<\/h3>\n

Opprett en liste over n\u00f8dvendige funksjoner<\/h4>\n

\u00c5 starte et vellykket prosjekt avhenger i stor grad av hvor godt du forst\u00e5r hva det faktisk handler om. Det inkluderer:<\/p>\n

- Forst\u00e5 kundens forventninger<\/p>\n

- Forst\u00e5else av prosjektets m\u00e5l og hovedm\u00e5l<\/p>\n

- Opprette en liste over n\u00f8dvendige funksjoner<\/p>\n

N\u00e5r du har g\u00e5tt gjennom kundens brief og har s\u00e5 mye informasjon om prosjektkravene som mulig, kan du liste opp alle funksjonene og sende dem videre til teamet ditt.<\/p>\n

Utvikle en produktreserve<\/h4>\n

For \u00e5 gj\u00f8re dette m\u00e5 du lage en etterslepsliste som best\u00e5r av alle funksjonene som skal gj\u00f8res. Deretter kan du prioritere dem, vurdere kompleksiteten og ansl\u00e5 hvor lang tid det vil ta \u00e5 fullf\u00f8re dem. En skikkelig etterslepsliste b\u00f8r best\u00e5 av<\/p>\n

- Brukerhistorier - beskriver handlingene som brukerne kan utf\u00f8re p\u00e5 hvert trinn i bruken av produktet<\/p>\n

- Akseptkriterier - liste opp de elementene som trengs for at en historie skal kunne fullf\u00f8res<\/p>\n

- Story points - estimer arbeidsmengde, risiko og kompleksitet i relativ poengverdi<\/p>\n

- Oppgaver for brukerhistorier - liste opp oppgavene som m\u00e5 gj\u00f8res for \u00e5 levere en brukerhistorie<\/p>\n

Det er avgj\u00f8rende \u00e5 involvere utviklingsteamet i utarbeidelsen og prioriteringen av produktetterslepet for \u00e5 sikre n\u00f8yaktige og realistiske vurderinger.<\/p>\n

Prioritering av funksjoner<\/h3>\n

Sorter funksjoner etter prioritet<\/h4>\n

N\u00e5r du har en liste over funksjoner klar, kan du prioritere hver enkelt av dem. Du kan bruke MoSCoW-analysemetoden til \u00e5 sortere dem slik:<\/p>\n

- M\u00e5 ha<\/p>\n

- Burde ha<\/p>\n

- Kunne ha<\/p>\n

- Vil ikke ha<\/p>\n

N\u00e5r du utvikler et prosjekt, m\u00e5 du fokusere p\u00e5 det du m\u00e5 levere i f\u00f8rste omgang. \u00c5 bygge en MVP gir deg muligheten til \u00e5 teste hypoteser om ideen din f\u00f8r du fullf\u00f8rer hele prosjektet, vise den til interessenter eller betabrukere og samle inn tilbakemeldinger som er viktige for den videre utviklingen av resten av funksjonene.<\/p>\n

Viktigheten av \u00e5 tildele prioritet<\/h4>\n

Prioritering kan ogs\u00e5 hjelpe deg med \u00e5 estimere prosjektet. N\u00e5r du fokuserer p\u00e5 de viktigste funksjonene og de du m\u00e5 gj\u00f8re f\u00f8rst, kan du gj\u00f8re mer n\u00f8yaktige antakelser om n\u00e5r de vil v\u00e6re ferdige. N\u00e5r det gjelder \"kunne ha\"-funksjoner, kan du begynne med et grovt estimat, ettersom de ligger lenger ut i utviklingsprosessen og mye kan endre seg innen teamet ditt kommer til dem (og hvis teamet ditt kommer til dem, ettersom du etter \u00e5 ha samlet inn tilbakemeldinger om MVP-en din kan snu og ikke inkludere alle de opprinnelig planlagte funksjonene).<\/p>\n

Omfattende estimering<\/h4>\n

Det er imidlertid viktig \u00e5 estimere alle funksjonene, uavhengig av prioritet (bortsett fra de som \"ikke skal v\u00e6re med\", selvf\u00f8lgelig), ettersom du \u00f8nsker \u00e5 f\u00e5 en oversikt over hele prosjektet p\u00e5 \u00e9n gang. Og n\u00e5r du kommer til de neste fasene av prosjektet, kan du revurdere arbeidsomfanget for \u00e5 sikre at estimatene dine fortsatt er n\u00f8yaktige.<\/p>\n

\"\"<\/figure>\n

Estimeringsteknikker<\/h3>\n

Estimeringsprosessen for Story Point<\/h4>\n

N\u00e5 som du har ferdigstilt produktetterslepet ditt, er det p\u00e5 tide \u00e5 estimere hvert enkelt element. For \u00e5 gj\u00f8re dette bruker vi story points. Dette er enheter Agile-team bruker for \u00e5 evaluere arbeidet som trengs for \u00e5 fullf\u00f8re hvert element i etterslepet. Story points bidrar til \u00e5 tildele relativ verdi til elementene i etterslepet. De er ikke relatert til tid og kan ha ulik verdi for ulike team, s\u00e5 de har ingen emosjonell verdi. Dermed er det stor sjanse for at teammedlemmene ikke vil \u00f8ke estimatene bare for \u00e5 v\u00e6re p\u00e5 den sikre siden. Planning Poker hjelper programvareteamene med \u00e5 planlegge arbeidsflyten og forbedre prosjektets leveringshastighet.<\/p>\n

Ved hjelp av story points kan et team estimere:<\/p>\n