Udgangspunktet for et scrum sprint er en prioriteret produkt backlog. Alle User Stories (nedbrudt fra feature A,B,C) som udtages til et sprint skal være ”Sprint Ready”.
”Sprint Ready” kriterier
I den prioriterede backlog indgår også hvilke kommende FEatures der skal udvikles. Disse skal analyseres / Groomes og nedbrydes til User Stories som er klare til det efterfølgende sprint. Se nedenstående figur.
Sprint planlægning foregår i 2 dele.
Del 1 :
Her fremlægger Product Owner (PO) sine mål for sprintet og de enkelte user stories udtaget til sprintet gennemgås. Desuden fremhæves hvilke Features der skal Groomes og nedbrydes til User Stories til det efterfølgende sprint. Her er det PO’s ansvar at sikre alle har samme forståelse for hvad der skal opnås.
Del 2:
Her nedbryder teamet hver User Story i Tasks og estimerer hver tasks i timer. Grooming arbejdet estimeres ved at nedbryde kommende udviklingsopgaver / features i analyse tasks, hvor disse ligeledes estimeres.
Når alle User story Tasks og Analyse Tasks er nedbrudt og estimeret summeres timerne. Teamet vurderer om de kan nå alle tasks i forhold til kapacitet til rådighed.
Resultatet af planlægningen er en Sprint Backlog der visualiseres på en fysisk tavle eller elektronisk tavle.
Læs eventuelt mere om Scrum Board her : Opbygning af Scrum Board
Teamet har i forbindelse med opstarten af det agile projekt besluttet hvilke udviklingsprincipper de bruger. Det kan fx Test Driven Development (TDD) eller eXtreme Programming (XP).
Læs mere her : Test Driven Development eller Feature Driven Development
Dette er et dagligt koordineringsmøde, hvor teamets medlemmer orienterer hinanden på hvad de har nået siden sidste daglige møde, hvad de skal nå i dag og om de har nogle blokeringer.
For hver task der arbejdes på angives det hvor mange timer der forventes at være tilbage.
I dette møde demonstreres de udviklede features og godkendes af PO. Der laves en status på sprintet og eventuelle User Stories der ikke er færdige overføres til sprint backloggen for næste sprint.
Der er 2 nøgletal som teamet bør drøfte. Dels er det teamets hastighed (Velocity) – som opgøres som det gennemsnitlige antal User Story Points teamet leverer i hvert sprint (Kun færdige User Stories medtages i beregningen). Dels er det Completion Rate, som angiver i procent hvor mange User Stories der bliver færdige i forhold til planen. Normalt bør Completion rate ligge mellem 90-100% for de gode teams
Formålet med dette møde er at teamet evaluerer hvad der gik godt og på hvilke område teamet kan forbedre sig. Der vælges typisk 2-3 indsatsområder som inkluderes i det efterfølgende sprint som Forbedrings User Stories. Her skal teamet arbejde aktivt med implementering af løsninger der vil forbedre samarbejdet.
Sprint længden kan være fra 1-6 uger og ved en start på Scrum vil det ofte være en fordel af starte med 3 eller 4 ugers sprint. Herefter kan teamet gå til 2 ugers sprint som normalt er den sprint længde der giver den bedste præstation.
Nedenstående figur er fra vores Scrum Survey med 99 respondenter (læs mere her)
I figuren har vi for hver sprint længde angivet hvilke Completion rates de forskellige teams har. For et 2 ugers sprint fremgår det, at langt de fleste teams i undersøgelsen har den bedste completion rate.
scrum sprint er god forrenting. scrum sprint kan koste millioner. scrum sprint har betydning for rekruttering af nye medarbejdere. scrum sprint er til for medarbejderen. scrum sprint. scrum sprint skla styrke mod sårbarheder. scrum sprint kræver efterfølger planlægning. scrum sprint skal drives af HR. scrum sprint er græn. scrum sprint er omvendt onboarding.scrum sprint alumni. scrum sprint eksempel. En god afsked er en god forretning
Få mere information om hvordan vi kan udvikle dig, dit team eller din organisation.
