Sprintplanlægning: Hvad er det & hvordan gør man?

Hvad er sprintplanlægning?

Sprintplanlægning er den indledende fase i en agil udviklingscyklus og er en del af agil projektplanlægning. På dette møde samles hele teamet til et sprintplanlægningsmøde for at definere det arbejde, der skal udføres i et sprint, og udarbejde en plan for at nå disse mål.

Sprintplanlægningsmødet er typisk struktureret i to dele:

1. Sprintets “hvorfor” og “hvad”: Teamet fastsætter sprintmålet og bliver enige om, hvad der skal udføres. Det udvælger de emner fra produktbackloggen, der skal behandles i sprintet. Projektplanlægningsværktøjer med funktioner til sprintplanlægning kan hjælpe med at organisere og prioritere backlogemner, så teamet forbliver fokuseret og afstemt i forhold til sprintmålene.
2. Sprintets “hvordan”: Udviklerne drøfter detaljerne i de enkelte backlogemner og opdeler dem i opgaver. Hver opgave tilpasses, så den kan færdiggøres på én arbejdsdag eller mindre, og kan følges med et opgavestyringsværktøj.

Afhængigt af sprintets længde varer planlægningsmødet mellem to og otte timer. Det bør tidsbegrænses i forhold til sprintets længde (f.eks. højst 4 timers møde for et sprint på to uger).

Ved mødets afslutning skal sprintmålet og de opgaver, der skal færdiggøres, være fastlagt, og sprintet skal officielt være begyndt.

Hvorfor er sprintplanlægning vigtig?

Sprintplanlægning er vigtig, fordi den fastlægger en klar retning for teamets kommende sprint. Når den udføres godt, kan en sprintplanlægningssession:

• Skabe en klar, fælles forståelse af projektets mål og målsætninger
• Give teams mulighed for at prioritere og udvælge arbejdsemner til det kommende sprint
• Fremme effektiv ressourceallokering og tidsstyring
• Fremme samarbejde og kommunikation mellem teammedlemmerne

Overordnet set er sprintplanlægning et vigtigt forberedende trin i agil projektstyring. Den lægger fundamentet for et velorganiseret og effektivt sprint, så teams kan levere resultater af høj kvalitet inden for den fastsatte tidsramme.

Hvem deltager i sprintplanlægning?

Kort sagt bør hele Scrum-teamet være involveret i sprintplanlægningen og deltage i Scrum-begivenheden i begyndelsen af hvert sprint. Disse teammedlemmer kan omfatte:

• Produktejeren: Bidrager med indsigt i produktvisionen, tydeliggør kravene og prioriterer de backlogemner, der skal med i sprintet.
• Scrum masteren (kaldes agil coach i nogle teams og må ikke forveksles med en projektleder): Faciliterer mødet, sikrer, at den aftalte arbejdsgang følges, og at deltagerne opnår en fælles forståelse af sprintmålet. 
• Udviklerne: Bidrager med teknisk ekspertise og indsigt i gennemførligheden af og den nødvendige indsats for at implementere brugerhistorier.

Af og til deltager interessenter fra virksomheden også som rådgivere, hvis de kan bidrage med et vigtigt perspektiv eller nyttig viden.

Sådan forbereder du sprintplanlægningsmødet

For at sikre et effektivt møde bør produktejeren (PO) forberede følgende:

1. Resultaterne fra den seneste sprintgennemgang og sprintretrospektiv samt interessenternes feedback i backloggen.
2. Et overblik over det arbejde, der allerede er udført.

Derudover bør produktejeren forberede sig til et sprintplanlægningsmøde ved at gennemføre flere processer, som jeg vil beskrive mere detaljeret nedenfor. Disse omfatter:

1. På forhånd at definere sprintmålet med tilknyttede prioriterede backlogelementer, der kan diskuteres under planlægningen.
2. Regelmæssigt at forfine backloggen, hvor de vigtigste poster opdateres.
3. At vurdere teamets hastighed og kapacitet for det næste sprint.

Jeg vil beskrive disse tre aktiviteter i detaljer nedenfor.

Stay Ahead of What Deserves Your Attention

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

Get Free Access

Have an account? Log In

Hvad er et sprintmål?

Under sprintplanlægningen bliver produktejeren og udviklerne enige om et specifikt sprintmål. Sprintmålet beskriver resultatet eller udfaldet af det nye sprint, som teamet arbejder på. Det er en kortsigtet milepæl på vejen mod det endelige produkt. 

Målet er, at der ved sprintets afslutning findes et leverbart produktinkrement, som allerede giver kunderne en fordel.

Hvad er en backlog?

Hvis du er produktejer, har du sandsynligvis hørt udtrykket "backlog" flere gange, end du kan tælle. Men hvad er det egentlig? På et grundlæggende niveau ved vi selvfølgelig alle, hvad det er – en liste over opgaver eller funktionaliteter, der skal færdiggøres. 

Men når det kommer til de små detaljer, såsom forskellen mellem en produktbacklog og en sprintbacklog, bliver tingene hurtigt komplicerede, så spænd sikkerhedsselen, og lad os dykke ned i det!

Produktbacklog kontra sprintbacklog

Scrumteamet samler alle brugerhistorier, epics og opgaver, der er nødvendige for at skabe det endelige produkt, i produktbackloggen. Og produktejeren prioriterer backlogelementerne, så historierne med den højeste værdi for kunderne ligger øverst. Denne prioritering foretages normalt sammen med udviklerne.

Produktbackloggen er dog ikke en endelig liste, der oprettes i begyndelsen af udviklingsfasen og derefter behandles. Nej, denne liste vokser og ændrer sig konstant over tid. 

Den vokser både gennem den viden, der opnås i sprintene, og gennem nye krav, der opstår fremadrettet. Derfor er det nødvendigt regelmæssigt at forfine backloggen for at håndtere disse ændringer.

Lad os for eksempel sige, at produktbackloggen består af alle de historier, der er nødvendige for at oprette et website, f.eks. startsiden, kontaktformularen og produktsiderne. Hvis marketingteamet pludselig indser, at de absolut har brug for en blogsektion på websitet, kan den inkluderes i backloggen og prioriteres derefter.

Til forskel fra produktbackloggen indeholder sprintbackloggen kun de backlogelementer, der er udvalgt til det aktuelle sprint, samt et overordnet sprintmål.

Sådan estimerer du elementer i backloggen

Hvor meget arbejde kan et team gennemføre i sprintet? Det er et af de centrale spørgsmål, som udviklerne skal besvare under sprintplanlægningen. For at kunne lave en forudsigelse udarbejder de et estimat. 

Det kan være ganske udfordrende, da teamet arbejder med mange ukendte variabler. Men med tiden og den erfaring, der opnås gennem gennemførte sprint, bliver teamet bedre og bedre til at udarbejde estimater.

Sådan beregner du teamets hastighed og kapacitet

Før estimeringen kan begynde, er det vigtigt at kende den gennemsnitlige præstation i de tidligere sprint (hastighed) og teamets tilgængelige kapacitet i det kommende sprint, som kan være reduceret på grund af undervisning, ferie osv. 

På baggrund af disse overvejelser estimerer teamet den mængde arbejde (hastighed), som det kan håndtere i sprintet, vurderer derefter de enkelte backlogelementer og vælger, hvor mange af dem der skal med i sprintbackloggen.

Lad os sige, at den gennemsnitlige hastighed var 40 historiepoint i løbet af de seneste par sprint (2-ugers cyklus), og at der ikke forventes nogen væsentlig reduktion i teammedlemmernes tilgængelighed. I så fald planlægger teamet ud fra at fastholde den samme hastighed (dvs. de backlogelementer, der udvælges til det kommende sprint, vil samlet udgøre omkring 40 historiepoint).

Selvom den gennemsnitlige tid til at fuldføre en opgave normalt kan registreres med et godt værktøj til tidsregistrering, kan du også bruge flere andre estimeringsmetoder til at udføre agil kapacitetsplanlægning og fastslå dit teams hastighed.

Estimeringsmetoder: En kort oversigt

Vil du gerne forstå estimeringskunsten bedre? Med forskellige metoder og variabler i spil kan det ofte føles som et skræmmende emne – men bare rolig! Ved at forstå det grundlæggende bliver du hurtigt godt rustet til at estimere din opgavebeholdning.

Historiepoint

Mange agile teams, der arbejder på langsigtede projekter, estimerer deres hastighed i historiepoint. 

Historiepoint er en abstrakt enhed, som teamet bruger til at estimere den indsats, der kræves for at fuldføre et element i opgavebeholdningen. Dette er baseret på tre kriterier:

1. Mængden af arbejde: Hvor mange underopgaver skal fuldføres for at fuldføre brugerhistorien?
2. Risici og usikkerhed: Er alle krav tydelige, eller kan der opstå uventede forsinkelser og ændringer?
3. Historiepunktets kompleksitet: Er de individuelle underopgaver forbundet med hinanden, så brugerhistoriens kompleksitet øges? Og er der afhængigheder uden for teamet?

Fibonacci-sekvensen & primtal

Agil planlægning ved hjælp af Fibonacci-sekvensen og primtal hjælper teams med at lave prognoser, der ikke blot er intuitivt baseret på optimisme, men i stedet er informeret af principper for numerisk logik. 

Hvis en brugerhistorie har mange variabler og er kompleks eller omfattende i sit omfang, betyder tildelingen af et højere tal på Fibonacci-skalaen, at teamet er forberedt på at afsætte tilstrækkelige ressourcer og en passende indsats til at gennemføre den – fordi de allerede kender den mængde arbejde, der ligger i en sådan opgave. 

På den anden side får historier med færre variabler eller enklere resultater tildelt lavere tal – hvilket muliggør en mere præcis budgettering af tid og energi. Kort sagt fjerner agil planlægning håb og drømme fra mødebordet og erstatter dem med nogle hårde, håndgribelige tal!

Husk dog, at historiepoint ikke nødvendigvis kan sammenlignes på tværs af softwareudviklingsteams, da hvert team estimerer omfanget en smule forskelligt. Det betyder, at det, som team A estimerer til at være en historie på 5 SP, kan være en historie på 8 SP for team B.

Estimering med historiepoint er også velegnet til mindre teams eller projekter, da teamet med denne metode vurderer opgaverne ud fra deres kompleksitet og den tid, det tager at behandle dem. Andre teknikker omfatter estimering af indsatsen baseret på T-shirt-størrelser eller planlægningspoker-metoden.

T-shirt-størrelser 

Estimering af elementer i opgavebeholdningen med T-shirt-størrelser er en interessant tilgang til at hjælpe med at prioritere projektopgaver. I stedet for at tildele et præcist antal timer eller dage til en opgave kan du tildele den en af fire størrelser (lille, mellemstor, stor og ekstra stor) afhængigt af dens grad af kompleksitet eller usikkerhed.

Det er en forenklet, men overraskende effektiv måde at sikre, at de rigtige opgaver bliver udført på det rigtige tidspunkt – uanset om du arbejder med små, mellemstore eller omfattende projekter, skal du blot vælge den størrelse, der passer. Sørg bare for, at alle, der er involveret i projektet, er enige om, hvordan hver størrelse svarer til et bestemt estimeret indsatsniveau!

Planlægningspoker

Hvis du leder efter en smart måde at estimere dine elementer i opgavebeholdningen på, hvorfor så ikke prøve planlægningspoker? 

Det er en populær teknik, der har eksisteret siden 2002, hvor James Grenning opfandt betegnelsen. 

Tilgangen er enkel: Teammedlemmerne angiver anonymt deres estimater ved at vælge kort fra sættet af planlægningspokerkort, som repræsenterer forskellige estimater (dvs. det estimerede antal historiepoint for elementet).

Det tilskynder alle til at formulere deres mening uden frygt for andres fordømmelse eller latterliggørelse. Når alle teammedlemmer har indtastet deres estimater, og der er opnået enighed, går teamet videre til det næste element.

More Articles

• Scrummastere vs. projektledere: Vigtige forskelle
• Kanban vs. agil: Hvad er forskellen?
• Agil kontra vandfaldsmetoden til projektledelse
• Kanban vs. Scrum: Forskelle og hvordan du vælger
• 3 vigtige ligheder mellem Lean- og Agile-metoder

Dagsordenen for sprintplanlægningen

Så du har gennemført alle de nødvendige forberedelser og er endelig nået frem til sprintplanlægningsmødet. Planlægningen af et Scrum-sprint følger normalt denne dagsorden:

1. Produktejeren (PO'en) præsenterer sit foruddefinerede sprintmål og deler sin idé om, hvordan produktets værdi kan øges i det kommende sprint. Det endelige sprintmål defineres i fællesskab af produktejeren og udviklerne.
2. PO'en angiver de (prioriterede) elementer fra produktbackloggen, der skal implementeres for at nå målet.
3. Teamet estimerer indsatsen for de individuelle poster, hvis dette ikke allerede er blevet gjort på forhånd (f.eks. under backlogforfinelsen). Om nødvendigt forfiner teamet individuelle poster eller indhold (f.eks. acceptkriterier af typen given-when-then).
4. Teamet vælger de produktbacklogelementer, som det vil levere inden sprintets afslutning. På dette tidspunkt drøfter produktejeren de opgaver, der skal udføres, med udviklerne på baggrund af kundeværdi og indsats. Er de valgte elementer tilstrækkelige til at opfylde sprintmålet og skabe værdi for kunden? I sidste ende beslutter udviklerne selv, hvor meget arbejde de påtager sig i sprintet. Vigtigt: Dette valg er ikke en forpligtelse over for produktejeren og interessenterne, men en forudsigelse baseret på indsatsestimatet og teamets gennemsnitlige hastighed.
5. Udviklerne samles derefter for at opdele de valgte backlogelementer i mindre opgaver. Ideelt set tilpasses disse arbejdspakker, så de kan færdiggøres på en dag eller mindre.
6. Sprintbackloggen består af det fælles aftalte sprintmål, de backlogelementer, der skal behandles, og planen for, hvordan de skal behandles.
7. Mange teams visualiserer sprintbackloggen og det arbejde, der skal udføres, på en Scrum-tavle. Hvert team har sin egen tavle og bruger forskellige kolonner til at dokumentere fremdriften i sprintet. Grundlæggende bør de vigtigste kolonner på alle tavler være følgende tre: "Skal udføres", "I gang", "Færdig".

I praksis opdeler mange Scrum-teams sprintplanlægningen i to faser: 

I den første del finder de første fire punkter på den ovenfor beskrevne dagsorden sted. Produktejeren og teamet afklarer spørgsmålene: “Hvorfor er dette sprint værdifuldt?” og “Hvad bliver implementeret i dette sprint?” Udviklerne gennemfører den anden del uden PO'en og fokuserer på, hvordan de udfører det valgte arbejde.

Skabelon til dagsorden for sprintplanlægningsmødet

Har du brug for en dagsordenskabelon til dine sprintplanlægningsmøder? Download vores klare og enkle skabelon, så du hurtigt kan komme i gang med dine sprintplanlægningsmøder. Du får også en tjekliste og en e-mailskabelon for ekstra bekvemmelighed. 

Tid til at Marie Kondo dine sprintplanlægningsmøder

Med denne omfattende vejledning er du nu klar til at få mest muligt ud af dine sprintplanlægningssessioner. Hvis du fandt denne vejledning nyttig, anbefaler vi også, at du læser vores vejledning om møder om projektplanlægning.

Ved at følge trinnene i dette indlæg kan produktejere være sikre på, at de får succes med at omdanne kaos til klarhed og hjælpe deres teammedlemmer med at få succes med deres næste sprint. Læs mere om Scrum-rammeværket og andre Scrum-ceremonier som den daglige Scrum her.

Hvis du vil holde dig opdateret med flere organisatoriske tips og fokusområder om emner relateret til at lede effektive produktdrevne projekter, inviterer jeg dig til at tilmelde dig The Digital Project Managers nyhedsbrev. Derfra vil vi fortsat dele indsigter fra brancheeksperter og projektledere over hele verden.