Det finns en anledning till att väderprognoserna säger att det finns 70 % risk för regn istället för att lova att det kommer att regna exakt klockan 15. De använder den information som finns tillgänglig, tar hänsyn till osäkerheten och uppdateras när nya data kommer in. Du kan fortfarande planera din eftermiddag utifrån dem, så länge du inte misstar prognosen för en garanti.
Sprintplanering fungerar enligt en liknande princip. Ett Scrum-team har en produktbacklogg, en uppskattning av sin tillgängliga kapacitet och ett mål som det vill uppnå. Men vissa detaljer i arbetet blir först tydliga allteftersom sprinten fortskrider. Att planera varje timme i förväg lämnar lite utrymme för sådana upptäckter, medan det blir svårare att avgöra vad som förtjänar uppmärksamhet om man går in utan en gemensam riktning.
Syftet är att enas om ett värdefullt resultat och uppskatta hur mycket arbete teamet kan utföra för att uppnå det. Utifrån detta kan teamet anpassa sin plan allteftersom det får mer information, utan att tappa sprintmålet ur sikte.
Denna guide behandlar förberedelse av backloggen, en tidsplanerad dagordning, praktiska kapacitetsberäkningar och ett exempel som visar hur man anpassar planen under sprinten.
TL;DR Sprintplaneringen samlar Scrum-teamet för att enas om ett sprintmål, välja uppgifter från backloggen och fastställa en preliminär leveransplan:
- Förbered dig genom att förfina kommande arbetsuppgifter och kontrollera tillgänglighet, oavslutade uppgifter, beroenden och definitionen av ”klart”.
- Basera prognosen på faktisk kapacitet och tidigare resultat, med hänsyn till ledighet, möten, supportuppgifter och osäkerhet, utan att räkna med åtaganden två gånger.
- Avsluta planeringen med en gemensam sprintbacklog och justera sedan leveransplanen i takt med att teamet lär sig mer, samtidigt som sprintmålet upprätthålls.
- Använd den två timmar långa exempelagendan och det färdiga kapacitetsexemplet som utgångspunkt och anpassa dem efter teamets behov
Vad är sprintplanering?
Sprintplanering är ett Scrum-möte som hålls i början av varje sprint för att komma överens om vad teamet vill uppnå och hur arbetet ska genomföras. Det samlar hela Scrum-teamet, inklusive produktägaren, Scrum-mästaren och utvecklarna. Andra specialister, såsom säkerhetsingenjörer eller kundansvariga, kan också delta när deras synpunkter kan hjälpa teamet att fatta välgrundade beslut.
Enligt Scrum Guide ska varje planeringsmöte resultera i tre saker: ett sprintmål som förklarar värdet av arbetet, ett urval av produktbackloggposter som stöder det målet och en preliminär plan för att leverera dem. Tillsammans bildar dessa sprintbackloggen, som utvecklarna fortsätter att uppdatera allteftersom sprinten fortskrider.
Enligt Scrum Guide får en sprint på en månad ta högst åtta timmar, och kortare sprintar kräver vanligtvis mindre tid. Med en väl genomarbetad backlog ryms dagordningen nedan på två timmar.
Om du inte är bekant med vissa av dessa termer täcker vår ordlista grunderna i agilt arbetssätt och Scrum.
De tre frågorna som sprintplaneringen besvarar
Varje sprintplaneringsmöte kretsar kring tre frågor:
- Varför är den här sprinten värdefull?
- Vad kan vi åstadkomma?
- Och hur ska vi få arbetet gjort?
Scrum Guide organiserar planeringen kring dessa frågor, med utgångspunkt i det värde du vill leverera. När alla är överens om det är det lättare att avgöra vilka backlog-poster som förtjänar uppmärksamhet och hur mycket arbete ditt team rimligen kan ta på sig.
| Fråga | Vem leder | Resultat | Exempel på en tvåveckorssprint |
|---|---|---|---|
| Varför är den här sprinten värdefull? | Produktägaren lägger fram förslag; hela teamet godkänner det | Sprintmål | Nya kunder kan betala med kort i kassan utan att behöva kontakta säljavdelningen |
| Vad kan göras under denna sprint? | Utvecklarna väljer ut, tillsammans med produktägaren | Utvalda backlog-poster | Formulär för kortbetalning, integration med betalningsleverantör, kvittens via e-post, felhantering |
| Hur ska det valda arbetet genomföras? | Utvecklare | Inledande arbetsplan | Uppgifterna delas upp i deluppgifter, ofta på en dag eller mindre vardera, där man från början kommer överens om ansvarsfördelningen |
Varför sprinten är viktig
Sprintmålet ger teamet något att sträva efter och hjälper intressenterna att förstå vad de kan förvänta sig. Kom överens om detta mål med ditt Scrum-team innan planeringsmötet avslutas.
Beskriv ett resultat som folk kan känna igen, till exempel ”Testanvändare kan bjuda in teammedlemmar”, snarare än ett arbetsmål som ”Slutför 34 storypoäng”. Om ett oväntat problem dyker upp hjälper målet teamet att avgöra vilket arbete som ska justeras samtidigt som det avsedda resultatet bibehålls.
Vad teamet kan hinna med under denna sprint
När ni har enats om målet är det dags att ta reda på vad teamet realistiskt sett kan leverera.
Utvecklare väljer ut backlog-poster i samråd med produktägaren, samtidigt som de beaktar tillgänglig kapacitet, tidigare prestationer och definitionen av ”färdigt”. Detta är också rätt tillfälle att se över eventuella befintliga åtaganden som kan påverka hur mycket tid teamet har för sprintarbetet.
Många team använder storypoäng för att jämföra den relativa arbetsinsatsen och komplexiteten hos backlog-posterna. En Fibonacci-skala kan hjälpa till att strukturera dessa diskussioner, särskilt när den arbetsinsats som krävs är oklar.
Om du är nybörjare när det gäller storypoäng eller vill se hur de används i praktiken, här är en genomgång av uppskattningsprocessen.
Hur teamet ska utföra arbetet
När backlog-posterna har valts ut tar utvecklarna reda på hur de ska omvandla dem till ett färdigt produktinkrement som uppfyller definitionen av ”färdigt”. Scrum Guide föreslår att större poster delas upp i mindre arbetsdelar, ofta av en storlek som tar en dag eller mindre att genomföra.
Det betyder inte att du behöver planera varje timme i sprinten. De första dagarna kan behöva en mer detaljerad plan, medan senare uppgifter kan lämnas öppna för justeringar när nya detaljer framkommer. Att behandla tidiga uppskattningar som fasta åtaganden kan sätta press på teamet att uppfylla de ursprungliga siffrorna, även om omfattningen ändras under arbetets gång.
Som Dave West, VD för Scrum.org, förklarar:
En prognos som används för att försvara ett datum inbjuder till just det beteende som undergräver förtroendet, som att överdriva uppskattningar, dölja risker eller i smyg omdefiniera vad som räknas som ”klart” för att nå ett visst tal.
En prognos som används för att försvara ett datum inbjuder till just det beteende som undergräver förtroendet, som att överdriva uppskattningar, dölja risker eller i smyg omdefiniera vad som räknas som ”klart” för att nå ett visst tal.
Vad är skillnaden mellan sprintplanering och förfining av backloggen?
Backlog-förfining ger ditt team en tydligare förståelse för det kommande arbetet innan det är dags att besluta vad som ska ingå i nästa sprint. Sprintplaneringen bygger vidare på den förberedelsen för att enas om ett mål, välja backlog-poster och fastställa en preliminär leveransplan.
De två aktiviteterna fyller olika syften inom Scrum:
| Dimension | Förfining av backloggen | Sprintplanering |
|---|---|---|
| Syfte | Förtydliga, dela upp och uppskatta kommande backlog-poster | Fastställ sprintmålet, välj arbetsuppgifter och planera leveransen |
| Tidsplanering | Pågår under hela sprinten | I början av varje sprint |
| Scrum-status | En fortlöpande aktivitet | Ett formellt Scrum-möte med en tidsram |
| Vem deltar | Produktägare och berörda utvecklare | Hela Scrum-teamet |
| Resultat | Backlog-poster med tydligare detaljer, uppskattningar och omfattning | Sprintbackloggen: sprintmålet, utvalda uppgifter och leveransplan |
Se till att tillräckligt många kommande backlog-poster är tillräckligt specificerade så att teamet har tydliga valmöjligheter under sprintplaneringen. Hur mycket förberedelse som behövs beror på hur snabbt prioriteringarna förändras och hur stor osäkerheten är. Poster längre ner i backloggen kan vara mindre detaljerade tills de närmar sig urvalsfasen.
Läs även: För mer vägledning, se våra artiklar om backlog-grooming och hur du håller din produktbacklog organiserad och prioriterad.
Så här förbereder du dig inför sprintplaneringen
Några dagar i förväg bör du kontrollera att backloggen är i ordning och att alla har den information de behöver för att kunna fatta beslut. På så sätt kan ni ägna mötet åt att diskutera vad som ska levereras och hur ni ska gå tillväga, utan att behöva reda ut varje krav från grunden.
Här är en checklista att gå igenom inför din nästa sprint:
- Utarbeta ett sprintmål: Låt produktägaren föreslå ett resultat som stöder det övergripande produktmålet och ger teamet konkreta punkter att diskutera
- Gå igenom produktbackloggen: Se till att de högst prioriterade uppgifterna är ordnade, förstådda och uppskattade där det behövs
- Kontrollera teamets tillgänglighet: Be utvecklarna att informera om planerad ledighet, supportskift och andra åtaganden som kan påverka deras kapacitet
- Gå igenom oavslutat arbete: Granska det som blivit kvar från föregående sprint och eventuella förbättringar som identifierats under retrospektiven
- Identifiera beroenden: Markera arbetsuppgifter som kräver insatser eller godkännande från ett annat team och klargör vem som ska samordna detta
- Gå igenom definitionen av ”färdigt”: Se till att alla förstår vilka kvalitetskrav varje avslutat backlog-objekt måste uppfylla
Om du planerar att hålla sprintretrospektiven och planeringsmötet tätt inpå varandra, se till att avsätta tillräckligt med tid för en ordentlig diskussion vid båda tillfällena. Slutsatserna från retrospektiven bör ligga till grund för nästa sprints plan, så se till att inget av mötena känns stressigt.
Agenda för sprintplanering: Ett tidsbestämt exempel för en tvåveckorssprint
För en tvåveckorssprint börjar du med ett två timmar långt planeringsmöte, särskilt om backloggen redan har förfinats. Planera in extra tid om arbetet innebär komplexa beroenden eller flera beslut som kräver diskussion.
Du kan anpassa denna exempelagenda efter ditt teams behov.
| Tid | Punkt på dagordningen | Vem leder | Förväntat resultat |
|---|---|---|---|
| 0:00–0:10 | Gå igenom resultatet från föregående sprint, oavslutat arbete och åtgärder från retrospektiven | Scrum Master leder mötet | Gemensam förståelse för vad som behöver uppmärksammas |
| 0:10–0:30 | Diskutera produktägarens föreslagna sprintmål och enas om det önskade resultatet | Hela Scrum-teamet | Ett utkast till sprintmål som alla förstår |
| 0:30–0:45 | Bekräfta teamets tillgänglighet och gå igenom eventuella kapacitetsbegränsningar | Utvecklare | En realistisk bild av tillgänglig kapacitet |
| 0:45–1:15 | Välj backlog-poster som stöder målet | Utvecklare, tillsammans med produktägaren | Ett urval av arbetsuppgifter som teamet tror sig kunna slutföra |
| 1:15–1:45 | Dela upp de valda uppgifterna och diskutera leveransmetoden | Utvecklare | En preliminär plan för att slutföra arbetet |
| 1:45–2:00 | Gå igenom beroenden, kontrollera säkerhetsgraden och fastställ sprintmålet | Hela Scrum-teamet | Ett överenskommet sprintmål och en sprintbacklog som är redo att användas av teamet |
Innan ni avslutar kan ni göra en snabb förtroendekontroll, till exempel Fist of Five, där alla betygsätter sitt förtroende för planen med mellan noll och fem fingrar. Om någon ger ett lågt betyg, fråga vad som ligger bakom oron. Det kan avslöja ett olöst beroende, en alltför ambitiös prognos eller ett krav som behöver diskuteras ytterligare.
Syftet är att lyfta fram eventuella problem medan det fortfarande finns tid att justera planen.
Så här genomför du sprintplanering i 6 steg
När du har förberett backloggen och bekräftat vilka som ska delta kan du starta planeringsmötet. Målet här är att hjälpa teamet att omvandla sina prioriteringar och tillgänglig kapacitet till en plan som de känner sig säkra på att kunna genomföra.
Steg 1: Gå igenom tidigare arbete och enas om ett sprintmål
Börja med en kort genomgång av vad som har slutförts, vad som återstår och om några åtgärder från retrospektiven bör påverka nästa sprint. Fokusera på allt som kan förändra teamets prioriteringar eller tillvägagångssätt, snarare än att gå igenom hela sprintgenomgången på nytt.
Låt sedan produktägaren presentera det föreslagna sprintmålet och förklara hur det stöder det övergripande produktmålet. Ge utvecklarna utrymme att ifrågasätta omfattningen, ta upp beroenden och föreslå justeringar.
Om målet till exempel är att låta kunderna slutföra köpet utan att behöva kontakta säljarna, ska ni enas om hur ett lyckat köp ser ut. Ingår betalningsbekräftelse och felhantering? Är automatisk leverans av kvitto nödvändigt för den första versionen?
Dessa diskussioner hjälper dig att definiera ett resultat som teamet kan arbeta mot. Formuleringen kan komma att förändras i takt med att backlog-poster väljs ut, men alla bör vara överens om det slutgiltiga målet innan planeringen avslutas.
Steg 2: Beräkna teamets tillgängliga kapacitet
Innan du väljer ut arbetsuppgifter ska du fastställa hur mycket tid dina utvecklare realistiskt sett kan ägna åt sprinten.
Börja med antalet arbetsdagar och varje persons förväntade tillgänglighet. Ta sedan hänsyn till planerad ledighet, Scrum-möten, supportuppgifter och andra kända åtaganden. Om en utvecklare ägnar halva veckan åt att hantera produktionsproblem är dessa timmar redan upptagna och kan inte användas för det planerade sprintarbetet.
En enkel beräkning är: Tillgänglig kapacitet = Totalt antal arbetstimmar − Kända åtaganden
Till exempel kan en utvecklare med 80 arbetstimmar under två veckor ha 8 timmars ledighet, 10 timmars möten och 12 timmars supporttjänstgöring. Det lämnar 50 timmar innan man tar hänsyn till eventuella ytterligare osäkerhetsfaktorer.
Jämför denna siffra med teamets tidigare resultat. Velocity visar hur mycket arbete teamet har slutfört i tidigare sprintar, medan kapaciteten återspeglar den tid som finns tillgänglig för denna sprint.
Proffstips: Om du använder timmar för kapacitetsplanering, håll dem åtskilda från storypoäng. De två mäter olika saker, och det finns ingen universell omräkningsfaktor mellan dem.
Steg 3: Omvärdera oavslutat arbete från föregående sprint
Oavslutade backlog-poster bör granskas på nytt innan du lägger till dem i den nya sprinten. En post som var viktig för två veckor sedan kan ha ändrat prioritet, eller så kan teamet ha lärt sig något som påverkar hur mycket arbete som återstår.
Gå igenom varje punkt med produktägaren och fundera på följande:
- Relevans: Stöder det fortfarande det föreslagna sprintmålet eller någon annan viktig produktprioritet?
- Återstående arbetsinsats: Hur mycket arbete återstår nu när en del av uppgiften har slutförts?
- Beroenden: Finns det något som hindrar teamet från att göra framsteg?
- Prioritet: Bör denna post prioriteras framför nyligen förfinade backlog-poster?
För arbete som fortfarande hör hemma i sprinten, använd den återstående arbetsinsatsen för att bedöma hur mycket kapacitet det kommer att kräva. En halvfärdig uppgift kan kräva mindre arbete än den ursprungliga uppskattningen, men den räknas fortfarande som oavslutad tills den uppfyller definitionen av färdig.
Steg 4: Välj backlog-poster som stöder målet
När ni har en klar bild av er kapacitet och det återstående arbetet kan utvecklarna välja de produktbackloggposter som de tror sig kunna slutföra.
Börja med uppgifter som direkt stöder sprintmålet. Diskutera deras acceptanskriterier, tekniska beroenden och eventuella osäkerhetsfaktorer som kan påverka leveransen. Om en uppgift är för omfattande eller oklar, överväg att dela upp den i mindre delar som kan leverera värde inom ramen för sprinten.
Det kan också finnas utrymme för underhåll eller andra produktprioriteringar, men kontrollera om det arbetet skulle kunna äventyra huvudmålet.
Hur mycket kapacitet bör du reservera?
Att planera endast 80 % av den tillgängliga kapaciteten kan vara en rimlig utgångspunkt för team som regelbundet hanterar oväntat supportarbete, men Scrum föreskriver ingen fast procentandel.
Om ditt team har upplevt frekventa avbrott kan du reservera 10–20 % av dess justerade kapacitet och jämföra den reserverade andelen med vad som behövdes under tidigare sprintar. Ett team med stabilt arbete och få avbrott kan behöva mindre. Ett team som stöder en live-tjänst med frekventa incidenter kan behöva mer.
Undvik att räkna samma åtagande två gånger. Om schemalagda supporttimmar redan har dragits av i steg 2 bör den extra buffertkapaciteten täcka osäkerheten utöver den kända arbetsbelastningen. Använd den resulterande kapaciteten som en vägledning för diskussionen, inte som ett mål att uppnå.
Kom ihåg: En sprint med ledig kapacitet är inte nödvändigtvis underplanerad. Om du har valt ut tillräckligt med arbete för att uppnå sprintmålet kan det skapa konkurrerande prioriteringar att fylla de återstående timmarna med uppgifter som inte har något samband med målet. Ibland är en mindre prognos mer realistisk, särskilt när det valda arbetet innebär betydande osäkerhet.
Steg 5: Dela upp arbetet och kontrollera beroenden
När du väl har valt ut backlog-posterna kan utvecklarna arbeta igenom hur de ska leverera dem. Detta kan innebära att större poster delas upp i uppgifter för utveckling, testning, integration och granskning.
Titta noga på arbetsordningen. Om kassagränssnittet är beroende av en integration med en betalningsleverantör bör teamet förstå när den integrationen måste vara klar. Om ett annat team måste godkänna en säkerhetsändring, klargör hur och när det beslutet kommer att fattas.
Planera det omedelbara arbetet mer detaljerat och lämna senare uppgifter öppna för vidare diskussion. Scrum Guide föreslår att utvalda uppgifter delas upp i mindre arbetsuppgifter, vanligtvis av en dags längd eller mindre, men det är utvecklarna som bestämmer hur arbetet ska organiseras och fördelas.
Kontrollera att planen tar hänsyn till definitionen av ”färdigt”, inklusive nödvändigt test- och integrationsarbete. Om ett beroendeförhållande skulle kunna förhindra leveransen, se över de valda uppgifterna eller justera leveransmetoden innan planen slutgiltigt fastställs.
Steg 6: Slutför och dela sprintbackloggen
Dokumentera sprintmålet, de utvalda produktbacklog-posterna och den initiala leveransplanen på en plats där teamet kan komma åt och uppdatera dem. Tillsammans ska dessa tydliggöra vad teamet strävar efter att uppnå och vilket arbete som behöver prioriteras härnäst.
Innan mötet avslutas ska du bekräfta att alla är överens om målet och ge alla en chans att ta upp eventuella kvarstående farhågor kring prognosen. Om ett viktigt beroendeförhållande eller kapacitetsproblem inte är löst, diskutera vad som behöver ändras innan teamet sätter igång.
Under sprinten ger det dagliga scrum-mötet utvecklarna möjlighet att granska framstegen mot målet och justera sprintbackloggen. Ett burndown- eller burnup-diagram kan hjälpa till att visa förändringar i framstegen, medan de underliggande uppgifterna ger detaljerad information. Om ny information påverkar det valda omfattningen kan utvecklarna diskutera justeringar med produktägaren utan att äventyra sprintmålet.
Exempel på sprintplanering: Ett team med 6 utvecklare
Låt oss se hur dessa beslut fungerar i praktiken.
Tänk dig att du planerar en två veckors sprint för en B2B-faktureringsprodukt. Ditt team består av sex utvecklare och har följande föreslagna sprintmål: ”Nya kunder ska kunna betala med kort i kassan utan att behöva kontakta säljavdelningen.”
Innan du väljer uppgifter från backloggen måste du veta hur mycket tid teamet har till förfogande. I det här exemplet antar vi att varje utvecklare har sex potentiella timmar för fokuserat projektarbete per dag, innan planerade Scrum-möten och andra åtaganden dras av.
Så här fungerar kapacitetsberäkningen över 10 arbetsdagar:
| Kapacitetsberäkning | Timmar |
|---|---|
| Grundkapacitet: 6 utvecklare × 10 dagar × 6 timmar | 360 |
| Planerad ledighet: 1 utvecklare borta i 2 dagar | −12 |
| Jourtjänst: 1 utvecklare med 50 % tillgänglighet | −30 |
| Scrum-aktiviteter: 8 timmar per utvecklare | −48 |
| Tillgänglig kapacitet | 270 |
| Reservera 20 % för oförutsett arbete | −54 |
| Tillgänglig kapacitet för planerat arbete | 216 |
Du har nu 216 timmar till förfogande för det planerade arbetet efter att ha avsatt en illustrativ buffert på 20 %. I praktiken skulle du välja den marginalen utifrån hur mycket oplanerat arbete som avbröt tidigare sprintar.
Välj de arbetsuppgifter som stöder sprintmålet
När kapaciteten har fastställts går utvecklarna igenom de backlog-poster som rör utcheckningen tillsammans med produktägaren.
Här är ett illustrativt urval baserat på deras initiala uppskattningar av arbetsinsatsen på uppgiftsnivå:
| Backlog-post | Uppskattad arbetsinsats |
|---|---|
| Skapa formuläret för kortbetalning | 48 timmar |
| Integrera betalningsleverantören | 88 timmar |
| Hantera misslyckade betalningar och valideringsfel | 50 timmar |
| Lägg till betalningsbekräftelse och leverans av kvitto | 24 timmar |
| Totalt planerat arbete | 210 timmar |
Dessa uppskattningar lämnar 6 timmar inom ramen för det planerade arbetet, plus en buffert på 54 timmar för oförutsett arbete. Teamet har också en förbättring av rapporteringspanelen i produktbackloggen. Även om den är värdefull bidrar den inte direkt till målet för den aktuella sprinten. Produktägaren och utvecklarna kommer överens om att lämna den till en framtida sprint.
Justera planen när något förändras
På dag sex inför betalningsleverantören en API-ändring som gör att en del av integrationen slutar fungera. Utvecklarna undersöker saken och uppskattar hur mycket extraarbete som krävs.
I stället för att fortsätta med den ursprungliga arbetsordningen diskuterar de konsekvenserna med produktägaren. Om åtgärden ryms inom den återstående kapaciteten kan de prioritera den och skjuta upp valfri utformning av kvitton eller någon annan uppgift med lägre prioritet. Betalningsbekräftelse och annat väsentligt arbete måste fortfarande uppfylla definitionen av färdigställande.
Om åtgärden är mer omfattande än väntat måste de omvärdera den återstående omfattningen och avgöra om sprintmålet fortfarande är möjligt att uppnå.
Teamet kanske avslutar med färre färdigställda backlog-poster än vad som ursprungligen förutsågs. Men om kunderna kan slutföra köpet som avsett och arbetet uppfyller definitionen av ”färdigt” har sprintmålet uppnåtts.
Exempel på sprintmål för andra team
Du kan tillämpa samma planeringsmetod på arbete utanför mjukvaruutveckling, även om Scrum i sig är ett specifikt ramverk med definierade ansvarsområden och händelser.
Ett marknadsföringsteam kan till exempel sätta upp ett mål som ”Publicera landningssidan för webbinariet och gör det möjligt för besökare att registrera sig utan manuell hjälp.” Ett driftsteam kan ha som mål att ”Se till att alla medarbetare i nästa intagningsgrupp har den utrustning och systemåtkomst som behövs redan första dagen.”
Båda målen beskriver resultat som kan vägleda teamets beslut under hela sprinten. Backlog-posterna och leveransplanerna kommer att skilja sig åt, men teamet måste ändå ta hänsyn till sin kapacitet och enas om hur en lyckad leverans ser ut.
Vanliga misstag vid sprintplanering och hur man åtgärdar dem
Sprintplaneringen kan stöta på problem när teamen använder storypoäng för att bedöma enskilda medarbetares prestationer, tar med otydliga backlog-poster till mötet, fördelar arbetet för stelt eller bortser från testkrav och externa beroenden.
Några små justeringar kan hjälpa dig att upptäcka dessa problem innan de påverkar leveransen.
| Misstag | Varför det orsakar problem | Så här åtgärdar du det |
| Att använda storypoäng för att mäta individuell prestation | Att jämföra utvecklare utifrån antalet slutförda poäng kan leda till överdrivna uppskattningar eller att man undviker komplexa arbetsuppgifter. | Se till att storypoängen fokuserar på prognoser på teamnivå. Gå igenom det färdigställda arbetet från flera sprintar och diskutera förändringar i uppskattningarna under förfiningsfasen. Utvärdera individuella prestationer utifrån kodkvalitet, samarbete och resultat. |
| Att ta med oklara backlog-poster i planeringen | Saknade acceptanskriterier eller obesvarade tekniska frågor förvandlar planeringen till en diskussion om vad som ska byggas, vilket lämnar mindre tid för att planera leveransen. | Klara upp frågor under förfiningen av backloggen så att utvecklarna kan göra en rimlig prognos. Om osäkerheten kvarstår, överväg en mindre, bättre förstådd arbetsuppgift. Sträva efter tillräcklig tydlighet för att kunna fatta ett beslut, snarare än perfekta specifikationer. |
| Tilldela varje uppgift till någon innan arbetet påbörjas | Fasta uppdrag gör det svårare att anpassa sig när prioriteringarna ändras eller när en utvecklare blir klar i förtid medan en annan behöver hjälp. | Låt utvecklarna organisera arbetet. Kom överens om omedelbara ansvarsområden och specialistinsatser, och låt sedan teammedlemmarna ta över, arbeta i par eller omfördela uppgifter under sprinten. Se till att arbetet är synligt för hela teamet. |
| Att lämna externa beroenden olösta | Saknade API-inloggningsuppgifter, säkerhetsgranskningar eller leveranser från ett annat team kan leda till att teamet tvingas vänta på arbete som det inte kan kontrollera. | Innan du slutför sprintbackloggen ska du identifiera vilka insatser som krävs, vem som ska samordna dem och när de förväntas vara klara. Om ett kritiskt beroende fortfarande är osäkert bör du överväga ett alternativt arbetsmoment eller ett mindre omfattande uppdrag som teamet kan leverera på egen hand. |
Om samma problem återkommer i flera sprintar, ta upp dem i sprintretrospektiven och enas om en förändring som ni kan testa under nästa sprint. Dessa mallar för sprintretrospektiv kan hjälpa er att dokumentera iakttagelser och uppföljningsåtgärder.
I slutet av sprinten använder du sprintgranskningsmötet för att tillsammans med intressenterna granska det färdigställda inkrementet och diskutera vad teamet ska ta itu med härnäst.
Så här genomför du sprintplanering i ClickUp
Sprintplanering kräver mer arbete när uppgifter, kapacitetsuppskattningar och planeringsbeslut är utspridda över olika verktyg. ClickUp samlar all denna information på ett ställe, så att teamet kan granska arbetet tillsammans med kapaciteten och se över planeringsbesluten när planen ändras.
Börja med ClickUps mall för agil sprintplanering. Mallens vyer för backlog, utvecklingsstatus och resurser hjälper dig att granska kommande arbete och förbereda dig inför planeringsdiskussionen.
Så här går du igenom de viktigaste besluten:
- Gör det enklare att bedöma kommande arbete: Samla krav, godkännandekriterier, prioriteringar och beroenden i en backlog-lista med ClickUp-uppgifter. Dessa detaljer hjälper utvecklare att diskutera omfattningen och uppskatta arbetsinsatsen innan de väljer ut arbetsuppgifter. Lägg till de valda uppgifterna i sprinten när teamet har enats om planen
- Fastställ ett konsekvent planeringsfönster: Ställ in sprintens längd och startdatum i ClickUp Sprints. Använd sprintpoäng eller tidsuppskattningar för att bedöma arbetsinsatsen och hjälpa teamet att avgöra hur mycket arbete det kan ta sig an
- Kontrollera om arbetet passar: Jämför tilldelat arbete med varje persons kapacitet i ClickUps arbetsbelastningsvy. Granska ojämn arbetsbelastning och diskutera eventuella ändringar innan prognosen slutgiltigt fastställs.
- Håll dagordningen och besluten nära arbetet: Använd ClickUp Docs för den tidsplanerade dagordningen, det föreslagna sprintmålet och länkar till relevanta uppgifter. Dokumentera beslut om omfattning och olösta frågor under mötet så att teamet kan återkomma till dem allteftersom arbetet fortskrider.
- Dokumentera planeringsdiskussionen: ClickUp AI Notetaker kan dokumentera möten i Zoom, Google Meet, Microsoft Teams eller SyncUps och spara en sammanfattning, viktiga beslut och åtgärdspunkter i ett dokument. Granska anteckningarna och uppdatera sedan sprintuppgifterna med överenskomna uppföljningar
- Använd framstegsdata som underlag för diskussionerna: Lägg till Sprint Burndown- eller Burnup-kort i ClickUp-dashboards för att granska avslutat arbete och återstående arbetsinsats. När framstegen avviker från planen, granska de relevanta uppgifterna för att upptäcka förseningar eller ändringar i omfattningen som behöver åtgärdas.
Innan nästa planeringsmöte, fråga Brain²: ”Vilka olösta beroenden uppstod under vårt senaste sprintplaneringsmöte?” Brain kan hämta sammanhang från sparade mötesanteckningar. Jämför dessa detaljer med de aktuella uppgifterna innan du använder dem som underlag för nästa prognos.
Priser för ClickUp
Passar bäst för: Scrum-team som hanterar flera sprintar, delade beroenden och varierande arbetsbelastningar och som behöver backloghantering, kapacitetsplanering och framstegsrapportering i ett och samma arbetsutrymme. Det passar också bra för team som samordnar sprintarbetet med bredare produkt- eller affärsprojekt.
Hoppa över detta om: Ditt team endast behöver en enkel Scrum-tavla med en liten backlog och minimal rapportering. ClickUps flexibilitet innebär att du själv får bestämma inställningarna för sprintar, vyer och fält. Vissa avancerade funktioner för sprintrapportering och automatisering kräver dessutom abonnemang på högre nivåer, vilket kanske inte är nödvändigt för ett enkelt arbetsflöde.
Hur mycket bör du planera innan en sprint börjar?
Ett sprintplaneringsmöte bör ge teamet tillräcklig klarhet för att kunna påbörja arbetet.
Den tidsplanerade dagordningen och kapacitetsexemplet ovan utgör en utgångspunkt. Anpassa dem efter teamets arbetsbelastning och jämför sedan prognosen med utfört arbete och avbrott för att förbättra nästa planering.
I ClickUp kan du länka planeringsanteckningar till sprintuppgifter och uppdatera sprintbackloggen när arbetet förändras. Teamet kan gå tillbaka till den överenskomna planen när de beslutar vad som ska justeras.
Vanliga frågor om sprintplanering
Vad är skillnaden mellan sprintplanering och releaseplanering?
Sprintplaneringen fokuserar på vad ditt team strävar efter att åstadkomma under en sprint och hur det ska leverera det arbetet. Releaseplaneringen tar hänsyn till ett längre perspektiv, till exempel vilka funktioner som kan bli tillgängliga under flera sprintar och när användarna kan förväntas få tillgång till dem. Releaseprognoser kan ändras i takt med att teamen lär sig mer, medan varje sprintmål styr arbetet inom den aktuella sprinten.
Behöver du en definition av ”redo” för sprintplaneringen?
Nej. Scrum kräver ingen formell definition av ”redo”. Vissa team använder en sådan för att fastställa gemensamma förväntningar på backlog-poster innan urvalet, till exempel tydliga krav, hanterbar omfattning och kända beroenden. Se till att dessa kriterier är tillräckligt lätta för att underlätta diskussionen utan att hindra teamet från att förfina posterna när det behövs.
Kan en sprint avbrytas efter planeringen?
Ja. Endast produktägaren kan avbryta en sprint, och avbrytande är ett alternativ när sprintmålet blir föråldrat, kanske på grund av att affärsprioriteringar eller marknadsförhållanden har förändrats avsevärt. En svår uppgift eller en felaktig uppskattning i sig är inte nödvändigtvis skäl nog för att avbryta.
Vad är skillnaden mellan en sprint och agil utveckling?
Agile är en bredare metod för att hantera arbete baserad på värdena och principerna i det agila manifestet. En sprint är en fast period på en månad eller mindre inom Scrum-ramverket, under vilken ett team arbetar mot ett sprintmål och skapar en användbar inkrement. Du kan följa agila principer utan att använda sprintar. Kanban, till exempel, stöder ett kontinuerligt arbetsflöde utan att kräva iterationer av fast längd.
Kan en sprint ha flera sprintmål?
I Scrum definieras ett sprintmål som sprintens enda mål. Du kan välja backlog-poster som stöder andra prioriteringar, så länge de inte äventyrar det målet. Om ditt team regelbundet behöver flera mål som inte hänger ihop, diskutera om arbetet bidrar till ett bredare gemensamt resultat eller om ni behöver lösa konkurrerande prioriteringar innan planeringen.
Bör man uppskatta buggar i storypoäng under sprintplaneringen?
Storypoäng är valfria i Scrum, även för buggar. Team som uppskattar buggar bör komma överens om när och varför de ska göra det. Kända fel kan bedömas under planeringen, medan buggar som upptäcks under utvecklingen kan ingå i det arbete som redan krävs för att uppfylla definitionen av färdigt. Undvik att räkna samma arbetsinsats två gånger.