Hvad er Sprint Planning?

Sprint Planning er den første begivenhed i Sprint, hvor Scrum-teamet lægger en plan for, hvad de vil opnå i Sprint.

Sprint Planning er den første begivenhed, der starter starten på hver Sprint. Det initierer Sprint ved at sætte et mål, definere det arbejde, der skal afsluttes, og skitsere, hvordan det vil blive udført af hele Scrum-teamet. 

Ved at definere et Sprint-mål kan teamet bruge dette som grundlag for at bestemme, hvilke produktbacklog-elementer de arbejder på i løbet af den Sprint.

Hvem er involveret i Sprint Planning?

Typisk er hele Scrum-teamet involveret i Sprint Planning og bør være obligatoriske deltagere ved Sprint Planning-mødet. 

Det Product Owner og Developers definerer Sprint-målet baseret på den værdi, de søger. Teamet af Developer'ere skal derefter blive enige om, hvordan de vil nå dette mål ved at identificere det påkrævede arbejde. EN Scrum Master faciliterer ofte Sprint Planning for at sikre, at diskussionen er effektiv, og at Scrum-teamet er enige om Sprint-målet, og at de relevante produktbacklog-elementer er inkluderet i Sprint-backlogen.

Hvis nogen af deltagerne mangler fra mødet, vil det gøre det svært at nå Sprint-målet, så det er vigtigt for alle at deltage. Scrum-teamet kan også invitere andre personer til at deltage for at give yderligere råd, hvis det er nødvendigt.

Hvornår finder Sprint Planning sted?

Sprint Planning-mødet finder sted på den første dag i et nyt Scrum Sprint

Da arrangementet finder sted efter gennemgangen af den tidligere Sprint, er det en god mulighed for at overveje diskussioner i retrospekt for at hjælpe den nye Sprint. Nogle hold vil måske også finde det en fordel at have en regelmæssig tid til Sprint Planning-mødet, så de kan sikre, at deres kalender er fri for andre engagementer.

Som nævnt i Scrum Guiden har Sprint Planning også en tidsboks, afhængigt af længden af Sprint. Det skal timeboxes på 8 timer eller mindre for en 1-måneders sprint.

Hvad skal forberedes til Sprint Planning-mødet?

At køre et vellykket Sprint Planning-møde kræver en vis planlægning. Som nævnt i det foregående afsnit er det en god mulighed for at bruge retrospektive erfaringer fra tidligere Sprint'er. Product Owner skal forberedes ved at kombinere erfaringerne fra den tidligere Sprint-gennemgang, med feedback fra interessenter og vision for produktet, så de kan sætte scenen for Sprint. Product Backlog bør raffineres for at skabe klarhed for holdet.

Hvad er strukturen for Sprint Planning-mødet?

Sprint Planning-mødet vil følge en struktur for at behandle nedenstående tre nøgleemner.

Emne 1: Hvorfor er denne Sprint værdifuld? Som vi har været inde på, bør Product Owner definere den værdi, de søger Hvad er Scrum-kapacitetfra produktet. Hele Scrum-teamet samarbejder derefter om at definere en Sprint Goal, der kommunikerer, hvorfor Sprint er værdifuld for interessenterne. Sprint Goal skal færdiggøres inden udgangen af Sprint Planning. 

Emne to: Hvad kan man gøre med denne Sprint? Developer'erne og Product Owner'erne samarbejder om, hvilke elementer fra efterslæbet, der kan opnås under den nuværende Sprint. Det er ofte udfordrende at definere, hvor meget arbejde der kan udføres inden for en Sprint. Developer'erne bør dog bruge deres erfaring med tidligere præstationer, kommende kapacitet og deres Definition of Done for at være sikker på deres Sprint-prognoser. 

Emne tre: Hvordan vil det valgte arbejde blive udført? Til det sidste emne planlægger Developer'erne det nødvendige arbejde for de udvalgte Product Backlog-emner. Dette kan opnås ved at identificere den opgave, der er nødvendig for at levere hver af Product Backlog. Normalt er opgaven arbejdet på en dag eller mindre. Det er vigtigt at forstå, at opgaver kan ændre sig i løbet af Sprint, men Sprint Goal forbliver.

Sprint Goal, Product Backlog-elementerne valgt til Sprint plus planen for levering af dem omtales tilsammen som Sprint Backlog.

Almindelige vanskeligheder i Sprint Planning

Der er et par almindelige fejl, som også bør overvejes. 

Ikke at have et klart defineret Sprint-mål vil svække Scrum-teamets evne til at levere. Det kan også resultere i, at teamet leverer en Sprint belastning af arbejde uden at føle, at der er sket fremskridt. Det er overflødigt at sige, at dette er en afgørende del af Sprint Planning for både struktur og teammoral. 

Ikke at tillade ændringer under Sprint Planning kan også udgøre en almindelig fejl. Det er vigtigt at forblive fleksibel, især da teamet fortsætter med at lære og udvikle sig. 

Sammenfatning af Sprint Planning

Sprint Planning er en vigtig begivenhed for at sikre succesen for hver Sprint. Det giver værdi ved at give et team mulighed for at starte hver Sprint med en gensidig forståelse af, hvad de vil arbejde på i løbet af Sprint, samt give en indledende plan for, hvordan de vil gribe det arbejde an.

Del:

Relateret blogindlæg

Misforståelser i softwarespecifikationer.

Der er ofte misforståelser i softwarespecifikationsdokumenter. Den løsning, vi typisk vælger, er at lave mere detaljerede specifikationer. Men det fører desværre ikke til bedre resultater.

Relateret uddannelse

Relaterede ressourcer

Sådan kører du en Retrospective.

At køre et effektivt retrospektiv er afgørende for løbende forbedringer i Agile-teams. Hvis du nogensinde har følt, at dit teams retrospektiver mangler retning eller ikke producerer handlingsrettede indsigter, er du...

Et cirkulært flowdiagram med forskellige faser, der repræsenterer scrum-processen

Scrum-processen forklaret

Få indblik i Scrum-processens finesser, og lær, hvordan dette agile-framework kan revolutionere projektledelse.

Et teleskop, der fokuserer på et fjernt

Hvad er en produktvision?

Opdag styrken ved en produktvision, og hvordan den former en virksomheds fremtid.

Flere ressourcer

Lad os snakke om
Hvordan vi kan hjælpe!

Nyder du vores artikler? Endnu bedre er det, hvis du kan tale med os personligt! Kontakt os, så vi kan planlægge noget!