Skip to main content

Är du redo att få ut mesta möjliga av sprintplaneringen? Som agil projektledare eller produktägare är det upp till dig att se till att alla är på samma sida och att leverera resultat. 

Det är alltså dags att rensa upp i kaoset och fastställa framgångskriterierna med den här ultimata guiden, som gör din sprintplanering så välorganiserad att du kan ge Marie Kondo en match! Även om ett bra agilt projekthanteringsverktyg kan vara till stor hjälp finns det inget som slår mänskligt tänkande och lagarbete när det gäller att skapa en framgångsrik sprintplan.

I den här omfattande guiden går jag därför igenom allt du behöver för att planera framgångsrika sprintar – inklusive att fastställa ett sprintmål, hur du förbereder dig inför sprintplaneringsmötet, hur du sammanställer mötesagendan och andra bästa praxis.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Vad är sprintplanering?

Sprintplanering är den inledande fasen i en agil utvecklingscykel och ingår i agil projektplanering. Under det här mötet samlas hela teamet till ett sprintplaneringsmöte för att definiera det arbete som ska utföras under en sprint och skapa en plan för att nå dessa mål.

Sprintplaneringsmötet är vanligtvis strukturerat i två delar:

  1. ”Varför” och ”vad” för sprinten: teamet fastställer sprintmålet och kommer överens om vad som ska göras. Det väljer ut de delar av produktbackloggen som ska behandlas under sprinten. Projektplaneringsverktyg med funktioner för sprintplanering kan hjälpa till att organisera och prioritera backloggobjekt, så att teamet håller fokus och är samordnat kring sprintmålen.
  2. ”Hur” sprinten ska genomföras: utvecklarna diskuterar detaljerna för de enskilda backloggobjekten och delar upp dem i uppgifter. Varje uppgift anpassas så att den kan slutföras på högst en arbetsdag och kan följas upp med ett uppgiftshanteringsverktyg.

Beroende på sprintens längd varar planeringsmötet mellan två och åtta timmar. Det bör tidsbegränsas utifrån sprintens längd (t.ex. högst fyra timmars möte för en tvåveckorssprint).

Vid mötets slut ska sprintmålet och uppgifterna som ska slutföras vara fastställda, och sprinten ska officiellt ha startat.

Varför är sprintplanering viktigt?

Sprintplanering är viktigt eftersom det skapar en tydlig riktning för teamets kommande sprint. När den genomförs på rätt sätt kan ett sprintplaneringsmöte:

  • Skapa en tydlig, gemensam förståelse för projektets mål och syften
  • Göra det möjligt för team att prioritera och välja arbetsobjekt för den kommande sprinten
  • Främja effektiv resursfördelning och tidshantering
  • Främja samarbete och kommunikation mellan teammedlemmarna

Sammantaget är sprintplanering ett viktigt förberedande steg i agil projektledning. Den lägger grunden för en välorganiserad och effektiv sprint, vilket gör det möjligt för team att leverera resultat av hög kvalitet inom den fastställda tidsgränsen.

Vilka deltar i sprintplaneringen?

Kort sagt bör hela Scrum-teamet vara involverat i sprintplaneringen och delta i Scrum-evenemanget i början av varje sprint. Dessa teammedlemmar kan vara:

  • Produktägaren: Bidrar med insikter om produktvisionen, förtydligar krav och prioriterar de backloggobjekt som ska ingå i sprinten.
  • Scrum mastern (som i vissa team kallas agil coach och inte ska förväxlas med en projektledare): Leder mötet, ser till att det överenskomna arbetsflödet följs och att deltagarna utvecklar en gemensam förståelse för sprintmålet. 
  • Utvecklarna: Bidrar med teknisk expertis och insikter om genomförbarheten och den insats som krävs för att implementera användarberättelser.

Ibland deltar även intressenter från företaget som rådgivare om de kan bidra med ett viktigt perspektiv eller användbar kunskap.

Så förbereder du dig inför sprintplaneringsmötet

För ett effektivt möte bör produktägaren (PO) förbereda följande:

  1. Resultaten från den senaste sprintgranskningen och sprintretrospektivet, samt feedback från intressenter i backloggen.
  2. En översikt över det arbete som redan har utförts.

Dessutom bör produktägaren förbereda sig inför ett sprintplaneringsmöte genom att genomföra flera processer, som jag kommer att diskutera mer i detalj nedan. Dessa omfattar:

  1. Fördefiniera sprintmålet med tillhörande prioriterade backloggposter som kan diskuteras under planeringen.
  2. Regelbundet förfina backloggen, där de viktigaste posterna uppdateras.
  3. Bedöma teamets hastighet och kapacitet inför nästa sprint.

Jag kommer att beskriva dessa tre aktiviteter i detalj nedan.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Vad är ett sprintmål?

Under sprintplaneringen kommer produktägaren och utvecklarna överens om ett specifikt sprintmål. Sprintmålet beskriver resultatet eller utfallet av den nya sprint som teamet arbetar med. Det är en kortsiktig milstolpe på vägen mot slutprodukten. 

Målet är att det i slutet av sprinten ska finnas ett levererbart produktinkrement som redan erbjuder kunderna en fördel.

Vad är en backlogg?

Om du är produktägare är chansen stor att du har hört termen "backlogg" fler gånger än du kan räkna. Men vad är det egentligen? På en grundläggande nivå vet vi förstås alla vad det är – en lista över uppgifter eller funktioner som behöver slutföras. 

När det däremot kommer till detaljer som skillnaden mellan en produktbacklogg och en sprintbacklogg blir saker snabbt komplicerade, så spänn fast dig och låt oss dyka ner i det!

Produktbacklogg kontra sprintbacklogg

Scrumteamet samlar alla användarberättelser, epics och uppgifter som krävs för att skapa slutprodukten i produktbackloggen. Produktägaren prioriterar sedan backloggposterna så att de berättelser som har högst värde för kunderna hamnar överst. Denna prioritering görs vanligtvis tillsammans med utvecklarna.

Produktbackloggen är dock inte en slutgiltig lista som skapas i början av utvecklingsfasen och sedan bearbetas. Nej, listan växer och förändras ständigt över tid. 

Den växer både genom den kunskap som samlas in under sprintarna och genom nya krav som uppstår framöver. Därför krävs regelbunden förfining av backloggen för att hantera dessa förändringar.

Anta till exempel att produktbackloggen består av alla berättelser som krävs för att skapa en webbplats, till exempel startsidan, kontaktformuläret och produktsidorna. Om marknadsföringsteamet plötsligt inser att de absolut behöver en bloggsektion på webbplatsen kan denna läggas till i backloggen och prioriteras därefter.

I jämförelse med produktbackloggen innehåller sprintbackloggen endast de backloggposter som har valts ut för den aktuella sprinten samt ett övergripande sprintmål.

Så uppskattar du poster i backloggen

Hur mycket arbete kan ett team slutföra under sprinten? Det är en av de centrala frågor som utvecklarna måste besvara under sprintplaneringen. För att kunna göra en prognos gör de en uppskattning. 

Det kan vara ganska utmanande eftersom teamet hanterar många okända variabler. Men med tiden och den erfarenhet som teamet får från genomförda sprintar blir deras uppskattningar allt bättre.

Så beräknar du teamets hastighet och kapacitet

Innan uppskattningen kan börja är det viktigt att känna till den genomsnittliga prestationen under de tidigare sprintarna (hastigheten) och teamets tillgängliga kapacitet inför den kommande sprinten, som kan vara reducerad på grund av utbildning, semester och så vidare. 

Utifrån dessa överväganden uppskattar teamet hur mycket arbete (hastighet) det kan hantera under sprinten, utvärderar sedan de individuella backloggposterna och väljer hur många av dem som ska inkluderas i sprintbackloggen.

Anta att den genomsnittliga hastigheten var 40 berättelsepoäng under de senaste sprintarna (en tvåveckorscykel) och att ingen betydande minskning av teammedlemmarnas tillgänglighet förväntas. Då kommer teamet att planera utifrån att behålla samma hastighet (det vill säga att de backloggposter som väljs ut för den kommande sprinten kommer att motsvara omkring 40 berättelsepoäng).

Även om den genomsnittliga tiden för att slutföra en uppgift vanligtvis kan spåras med ett bra verktyg för tidsspårning, kan du också använda flera andra uppskattningsmetoder för att utföra agil kapacitetsplanering och fastställa teamets leveranstakt.

Uppskattningsmetoder: en kort översikt

Vill du förstå uppskattningskonsten bättre? Med olika metoder och variabler i spel kan det ofta kännas som ett skrämmande ämne – men oroa dig inte! Genom att förstå grunderna blir du snart väl rustad för att uppskatta din backlog.

Berättelsepoäng

Många agila team som arbetar med långsiktiga projekt uppskattar sin leveranstakt i berättelsepoäng. 

Berättelsepoäng är en abstrakt enhet som teamet använder för att uppskatta den arbetsinsats som krävs för att slutföra ett backlogobjekt. Detta baseras på tre kriterier:

  1. Arbetsmängd: Hur många deluppgifter måste slutföras för att slutföra användarberättelsen?
  2. Risker och osäkerhet: Är alla krav tydliga, eller kan det uppstå oväntade förseningar och förändringar?
  3. Berättelsens komplexitet: Är de enskilda deluppgifterna kopplade till varandra, så att berättelsens komplexitet ökar? Och finns det beroenden utanför teamet?

Fibonaccisekvensen och primtal

Agil planering med hjälp av Fibonaccisekvensen och primtal hjälper team att göra prognoser som inte bara bygger på intuitiv optimism, utan i stället grundas på principer för numerisk logik. 

Om en användarberättelse har många variabler och är komplex eller omfattande till sin omfattning innebär tilldelningen av ett högre tal på Fibonacciskalan att teamet är förberett på att avsätta tillräckligt med resurser och arbetsinsats för att slutföra den – eftersom de redan känner till den arbetsmängd som ingår i ett sådant åtagande. 

Å andra sidan tilldelas berättelser med färre variabler eller enklare resultat lägre tal – vilket möjliggör en mer exakt budgetering av tid och energi. Kort sagt tar agil planering bort förhoppningar och drömmar från styrelserumsbordet och placerar hårda, konkreta tal där i stället!

Kom dock ihåg att berättelsepoäng inte nödvändigtvis är jämförbara mellan team för programvaruutveckling, eftersom varje team uppskattar omfattningen på ett lite annorlunda sätt. Det innebär att det som team A uppskattar som en berättelse på 5 berättelsepoäng kan vara en berättelse på 8 berättelsepoäng för team B.

Uppskattning med berättelsepoäng lämpar sig också för mindre team eller projekt, eftersom teamet med denna metod utvärderar uppgifterna utifrån deras komplexitet och den tid det tar att hantera dem. Andra tekniker omfattar att uppskatta arbetsinsatsen utifrån T-shirtstorlekar eller metoden planeringspoker.

T-shirtstorlekar 

Att uppskatta backlogobjekt med T-shirtstorlekar är ett intressant sätt att hjälpa till att prioritera projektuppgifter. I stället för att tilldela en uppgift ett exakt antal timmar eller dagar kan du tilldela den en av fyra storlekstyper (liten, medelstor, stor eller extra stor), beroende på graden av komplexitet eller osäkerhet.

Det är ett förenklat men förvånansvärt effektivt sätt att se till att rätt uppgifter blir gjorda vid rätt tidpunkt – oavsett om du arbetar med små, medelstora eller storskaliga projekt behöver du bara välja den storlek som passar. Se bara till att alla som deltar i projektet är överens om hur varje storlek motsvarar en specifik uppskattad arbetsinsats!

Planeringspoker

Om du letar efter ett smart sätt att uppskatta dina backlogobjekt, varför inte prova planeringspoker? 

Det är en populär teknik som har funnits sedan 2002, då James Grenning myntade begreppet. 

Metoden är enkel: teammedlemmarna lämnar anonymt sina uppskattningar genom att välja kort från kortleken för planeringspoker, där korten representerar olika uppskattningar (det vill säga det uppskattade antalet berättelsepoäng för objektet).

Detta uppmuntrar alla att uttrycka sin åsikt utan rädsla för andras omdömen eller hån. När alla teammedlemmar har lämnat sina uppskattningar och en samsyn har nåtts går teamet vidare till nästa objekt.

Agendan för sprintplaneringen

Du har alltså gjort alla nödvändiga förberedelser och har äntligen kommit till sprintplaneringsmötet. Planeringen av en Scrum-sprint följer vanligtvis följande agenda:

  1. Produktägaren (PO) presenterar sitt fördefinierade sprintmål och delar sin idé om hur produktens värde kan ökas under den kommande sprinten. Det slutliga sprintmålet definieras gemensamt av produktägaren och utvecklarna.
  2. PO:n anger de (prioriterade) poster från produktbackloggen som bör implementeras för att uppnå målet.
  3. Teamet uppskattar arbetsinsatsen för de enskilda posterna, om detta inte redan har gjorts tidigare (t.ex. vid förfining av backloggen). Vid behov förfinar teamet enskilda poster eller innehåll (t.ex. acceptanskriterier enligt given-när-så).
  4. Teamet väljer de produktbackloggposter som det ska leverera innan sprinten är slut. I detta skede diskuterar produktägaren de uppgifter som ska slutföras med utvecklarna utifrån kundvärde och arbetsinsats. Är de valda posterna tillräckliga för att uppfylla sprintmålet och skapa värde för kunden? I slutändan avgör utvecklarna själva hur mycket arbete de tar på sig under sprinten. Viktigt: Detta urval är inte ett åtagande gentemot produktägaren och intressenterna, utan en prognos baserad på arbetsinsatsen och teamets genomsnittliga hastighet.
  5. Utvecklarna samlas sedan för att dela upp de valda backloggposterna i mindre uppgifter. Idealt är dessa arbetspaket utformade så att de kan slutföras på en dag eller mindre.
  6. Sprintbackloggen består av det gemensamt överenskomna sprintmålet, de backloggposter som ska bearbetas och planen för hur dessa ska bearbetas.
  7. Många team visualiserar sprintbackloggen och det arbete som ska utföras på en Scrum-tavla. Varje team har sin egen tavla och använder olika kolumner för att dokumentera framstegen under sprinten. I grunden bör de viktigaste kolumnerna på alla tavlor vara följande tre: ”Att göra”, ”Pågår”, ”Klart”.

I praktiken delar många Scrum-team upp sprintplaneringen i två faser: 

I den första delen genomförs de fyra första punkterna i agendan som beskrivs ovan. Produktägaren och teamet klargör frågorna: ”Varför är denna sprint värdefull?” och ”Vad kommer att implementeras i denna sprint?” Utvecklarna genomför den andra delen utan PO:n och fokuserar på hur de ska utföra det valda arbetet.

Mall för agenda för sprintplaneringsmöte

Behöver du en agendamall för dina sprintplaneringsmöten? Ladda ner vår tydliga och lättanvända mall för att snabbt komma igång med dina sprintplaneringsmöten. Du hittar även en checklista och en e-postmall för extra bekvämlighet. 

Dags att Marie Kondo-anpassa dina sprintplaneringsmöten

Med den här omfattande guiden är du nu redo att få ut mesta möjliga av dina sprintplaneringssessioner. Om du tyckte att den här guiden var användbar rekommenderar vi även att du tar en titt på vår guide till möten för projektplanering.

Genom att följa stegen som beskrivs i det här inlägget kan produktägare vara säkra på att de lyckas omvandla kaos till tydlighet och hjälpa sina teammedlemmar att lyckas med sin nästa sprint. Läs mer om Scrum-ramverket och andra Scrum-ceremonier, som daglig Scrum, här.

För att hålla dig uppdaterad med fler organisatoriska tips och fördjupningar inom ämnen som rör genomförandet av effektiva produktdrivna projekt vill jag bjuda in dig att prenumerera på nyhetsbrevet från The Digital Project Manager. Därifrån kommer vi att fortsätta att dela insikter från branschexperter och projektledare över hela världen.