{"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\/sv\/projektledning\/hur-man-uppskattar-projekt\/","title":{"rendered":"Planering Poker Uppskattningsteknik och Story Points"},"content":{"rendered":"
\n\t
\n\t\t
\n\t\t\t

Utmaningen med felaktiga uppskattningar<\/h3>\n

Felaktiga uppskattningar \u00e4r en av de mest popul\u00e4ra utmaningarna inom projektledning. N\u00e4r du startar ett nytt IT-projekt vill du veta tv\u00e5 saker: hur l\u00e5ng tid det kommer att ta och hur mycket det kommer att kosta. F\u00f6r att kunna svara p\u00e5 dessa fr\u00e5gor m\u00e5ste du uppskatta de projekt du ska driva. Det finns ingen magisk regel som s\u00e4ger att projekt X tar 12 veckor och kostar $150.000. Eller att en Y-liknande webbplats tar 10 veckor att utveckla och kostar $100.000.<\/p>\n

Viktiga fr\u00e5gor besvaras i denna artikel<\/h3>\n

Vad du kommer att l\u00e4ra dig av den h\u00e4r artikeln:<\/p>\n

- Hur f\u00f6rbereder sig projektledare f\u00f6r kostnadsber\u00e4kning i projektledning?<\/p>\n

- Vilka uppskattningstekniker \u00e4r anv\u00e4ndbara f\u00f6r projektuppskattning?<\/p>\n

- Hur mycket planering kr\u00e4vs f\u00f6r att f\u00f6rbereda sig f\u00f6r att ber\u00e4kna kostnader med hj\u00e4lp av formler?<\/p>\n

\"\"<\/figure>\n

Vikten av korrekta uppskattningar<\/h3>\n

Du kan inte bed\u00f6ma ett projekts tidslinje eller kostnad utan en noggrann uppskattning, \u00e4ven om projektets omfattning \u00e4r mycket lik det du har gjort tidigare. Men det blir \u00e4nnu v\u00e4rre: en uppskattning kommer aldrig att ge dig ett 100% korrekt svar p\u00e5 dessa fr\u00e5gor ocks\u00e5. S\u00e5 varf\u00f6r g\u00f6r vi uppskattningar? F\u00f6r att det \u00e4r det enda s\u00e4ttet att g\u00f6ra antaganden om projektets tidslinje och budget, arbetsbelastningen och de resurser som beh\u00f6vs f\u00f6r att leverera det.<\/p>\n

\"\"<\/figure>\n

F\u00f6rdelar med korrekta uppskattningar<\/h3>\n

Genom att uppskatta projektet kan du ocks\u00e5 schemal\u00e4gga medarbetare med r\u00e4tt erfarenhet och kompetens. Det du kan g\u00f6ra \u00e5t det \u00e4r att anv\u00e4nda metoder och tekniker som g\u00f6r att du kan estimera med st\u00f6rsta m\u00f6jliga noggrannhet. S\u00e5 h\u00e4r anv\u00e4nder du Agile-metoden och Planning Poker-tekniken f\u00f6r att skapa meningsfulla uppskattningar av ditt projekt.<\/p>\n

\"\"<\/figure>\n

Planeringspokerns ursprung<\/h3>\n

Var kom Scrum (Planning) Poker ifr\u00e5n?<\/h4>\n

James Grenning utvecklade 2002 den planeringspokersession som \u00e4r k\u00e4nd f\u00f6r sin strategi, kallad Scrum poker. Under b\u00f6rjan av 1950-talet var hans uppskattningsmetod, Wide band Delphi, f\u00f6r tidskr\u00e4vande och hade andra begr\u00e4nsningar. I Grennings fall handlade pokerplanen ursprungligen om att ta itu med ett problem d\u00e4r spelarna var f\u00f6r entusiastiska och \u00f6verdrivet fokuserade f\u00f6r att vinna. Mike Cohn, grundare av Agile alliances och Scrum alliances, anv\u00e4nde senare den h\u00e4r tekniken i en artikel med titeln Agile Estimation and Planning.<\/p>\n

\"\"<\/figure>\n

Steg till korrekt projektuppskattning<\/h3>\n

Skapa en lista \u00f6ver n\u00f6dv\u00e4ndiga funktioner<\/h4>\n

Att starta ett framg\u00e5ngsrikt projekt beror till stor del p\u00e5 hur v\u00e4l du f\u00f6rst\u00e5r vad det faktiskt handlar om. Det inkluderar:<\/p>\n

- F\u00f6rst\u00e5 kundens f\u00f6rv\u00e4ntningar<\/p>\n

- F\u00f6rst\u00e5else f\u00f6r projektets m\u00e5l och dess huvudsyfte<\/p>\n

- Skapa en lista \u00f6ver n\u00f6dv\u00e4ndiga funktioner<\/p>\n

N\u00e4r du har g\u00e5tt igenom kundens brief och f\u00e5tt s\u00e5 mycket information om projektkraven som m\u00f6jligt kan du lista alla funktioner och skicka dem till ditt team.<\/p>\n

Utveckla en produktbacklog<\/h4>\n

F\u00f6r att g\u00f6ra det skapar du en produktbacklog som best\u00e5r av alla funktioner som ska g\u00f6ras. Du kan sedan prioritera dem, utv\u00e4rdera deras komplexitet och uppskatta hur l\u00e5ng tid det tar att slutf\u00f6ra dem. En korrekt produktbacklog b\u00f6r best\u00e5 av:<\/p>\n

- Anv\u00e4ndarber\u00e4ttelser - beskriver de \u00e5tg\u00e4rder som anv\u00e4ndarna kan vidta vid varje steg i anv\u00e4ndningen av produkten<\/p>\n

- Acceptanskriterier - lista de punkter som kr\u00e4vs f\u00f6r att en ber\u00e4ttelse ska kunna slutf\u00f6ras<\/p>\n

- Story points - uppskatta m\u00e4ngden arbete, risker och komplexitet i relativt po\u00e4ngv\u00e4rde<\/p>\n

- Uppgifter f\u00f6r anv\u00e4ndarber\u00e4ttelser - lista de uppgifter som beh\u00f6ver utf\u00f6ras f\u00f6r att leverera en anv\u00e4ndarber\u00e4ttelse<\/p>\n

Det \u00e4r viktigt att involvera utvecklingsteamet i arbetet med att skapa och prioritera produktbackloggen f\u00f6r att s\u00e4kerst\u00e4lla korrekta och realistiska bed\u00f6mningar.<\/p>\n

Prioritering av funktioner<\/h3>\n

Sortera funktioner efter prioritet<\/h4>\n

N\u00e4r du har en lista med funktioner klar ska du prioritera var och en av dem. Du kan anv\u00e4nda MoSCoW-analysmetoden f\u00f6r att sortera dem enligt f\u00f6ljande:<\/p>\n

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

- B\u00f6r ha<\/p>\n

- Kunde ha<\/p>\n

- Kommer inte att ha<\/p>\n

N\u00e4r du utvecklar ett projekt ska du fokusera p\u00e5 det du m\u00e5ste leverera i f\u00f6rsta hand. Genom att bygga en MVP f\u00e5r du m\u00f6jlighet att testa hypoteser om din id\u00e9 innan du slutf\u00f6r hela projektet, visa den f\u00f6r intressenter eller betaanv\u00e4ndare och samla in feedback som \u00e4r viktig f\u00f6r vidareutvecklingen av resten av funktionerna.<\/p>\n

Vikten av att tilldela prioritet<\/h4>\n

Att prioritera kan ocks\u00e5 hj\u00e4lpa dig att uppskatta projektet. N\u00e4r du fokuserar p\u00e5 huvudfunktionerna och de som du m\u00e5ste g\u00f6ra f\u00f6rst kan du g\u00f6ra mer exakta antaganden om n\u00e4r de ber\u00e4knas vara klara. F\u00f6r \"kan ha\"-funktioner kan du b\u00f6rja med en ungef\u00e4rlig uppskattning, eftersom de befinner sig l\u00e4ngre fram i utvecklingsprocessen och mycket kan f\u00f6r\u00e4ndras innan ditt team hinner ta itu med dem (och om ditt team hinner ta itu med dem, eftersom du efter att ha samlat in feedback om din MVP kan \u00e4ndra dig och inte inkludera alla de ursprungligen planerade funktionerna).<\/p>\n

Omfattande uppskattning<\/h4>\n

Det \u00e4r dock viktigt att uppskatta alla funktioner, oavsett prioritet (utom de som inte ska vara med, f\u00f6rst\u00e5s), eftersom du vill f\u00e5 en \u00f6verblick \u00f6ver hela projektet p\u00e5 en g\u00e5ng. Och n\u00e4r du kommer till n\u00e4sta steg i projektet kan du omv\u00e4rdera omfattningen av arbetet f\u00f6r att se till att dina uppskattningar f\u00f6rblir korrekta.<\/p>\n

\"\"<\/figure>\n

Tekniker f\u00f6r uppskattning<\/h3>\n

Process f\u00f6r uppskattning av ber\u00e4ttelsepunkter<\/h4>\n

Nu n\u00e4r du har din produktbacklog klar \u00e4r det dags att uppskatta var och en av dess punkter. F\u00f6r att g\u00f6ra det anv\u00e4nder vi story points. De \u00e4r enheter som Agile-team anv\u00e4nder f\u00f6r att utv\u00e4rdera det arbete som kr\u00e4vs f\u00f6r att slutf\u00f6ra varje objekt fr\u00e5n backloggen. Story points hj\u00e4lper till att tilldela relativt v\u00e4rde till artiklarna i produktbackloggen. De \u00e4r inte relaterade till tid och kan ha olika v\u00e4rden f\u00f6r olika team, s\u00e5 de har inte det k\u00e4nslom\u00e4ssiga v\u00e4rdet. D\u00e4rf\u00f6r \u00e4r det troligt att teammedlemmarna inte kommer att fylla i uppskattningarna bara f\u00f6r att vara p\u00e5 den s\u00e4kra sidan. Planning Poker hj\u00e4lper programvaruteam att planera arbetsfl\u00f6den och f\u00f6rb\u00e4ttra projektets leveranshastighet.<\/p>\n

Med hj\u00e4lp av story points kan ett team g\u00f6ra en uppskattning:<\/p>\n