Løberne står klar ved startpositionerne, skoene er kridtet og ruten målt op; men ved du hvordan du kommer succesfuldt i mål? Gennem oceaner af coaching sessioner med et hav af Scrum teams har jeg set mange forskellige måder at planlægge et sprint – både gode og dårlige. Ligesom i mange andre aspekter af livet, findes der ikke en “silver bullet” der matcher alle teams, men i det følgende vil jeg belyse én af de bedre praktikker.
I teorien
Den officielle definition af Sprint planlægningsmødet beskriver formålet med mødet til at besvare følgende spørgsmål:
- Hvad bliver der leveret som følge af det kommende Sprint?
- Hvordan vil man arbejde for at opnå den leverance?
Yderligere er der sat en tentativ timebox på 8 timer for hele seancen, delt med 4 timer på hvert af ovenstående spørgsmål, for et 4 ugers sprint. Deltagere ved mødet er hele Scrum teamet, hvilket betyder Product Owner, Scrum Master samt Development team.
I første del af mødet præsenterer Product Owner de elementer fra Product Backlog som denne ønsker behandlet. Efterfølgende definerer alle deltagere sammen et sprint goal som er målsætningen for hvad der bliver leveret efter sprintet.
I anden del af mødet nedbryder Development teamet opgaverne fra første del og designer hvordan løsningen overordnet skal se ud.
Output fra mødet er en sprint plan som teamet forpligter sig til at overholde i det kommende sprint.
I praksis
I min erfaring er der mange gode alternative måder at foretage planlægning af et kommende sprint. Det er dog klart at de to spørgsmål nævnt ovenfor – hvad bliver leveret og hvordan vil teamet arbejde – skal kunne besvares inden sprintet for alvor kan begynde.
Her er en løs opskrift baseret på de erfaringer jeg har opsnappet:
- Den totale kapacitet i teamet i næste sprint beregnes – altså opsummering af antal timer til rådighed til “real work” for hele teamet
- Baseret på historik sættes en successfaktor for teamet. Successfaktoren angiver hvor stor en andel af teamets kapacitet der skal planlægges for. Nye teams starter ofte med en successfaktor på 50 % mens mere erfarne ligger på 80-90 %. Det er vigtigt at planlægge med en success!
- I løbet af indeværende sprint samarbejder Development team med Product owner for at få detaljerne og forståelse på plads angående de højest prioriterede elementer på Product backloggen*
- Ready-to-sprint. Så snart elementerne opnår en tilstand af “ready-to-sprint” kan Development teamet begynde at nedbryde til konkrete arbejdsopgaver*
- Der nedbrydes aldrig flere Product backlog elementer end der er plads til i det kommende sprint
- Sprint planlægningsmøde. Ved selve sprint planlægningsmødet diskuterer hele Scrum teamet planen for næste sprint og fastsætter et Sprint goal. Det er vigtigt at alle forstår kompleksitet og forretningsbehov – specielt hvis ikke alle har deltaget i nedbrydningsarbejdet. Mødet afsluttes med at teamet forpligter sig til at levere i følge planen – selve seancen tager 1-2 timer afhængig af teamet
* Disse punkter bearbejdes ofte i såkaldte “Product backlog refinement” møder. Her samarbejder Product owner med enten hele Development teamet eller udvalgte medlemmer fra teamet. Formålet er at tilføje viden og detaljer til de højest prioriterede elementer på Product backloggen.
Opsummering
Ovenstående pragmatiske tilgang til sprint planlægning følger ikke slavisk den teoretiske ramme som Scrum guiden foreskriver:
- Hele teamet er ikke nødvendigvis med til at nedbryde alle opgaverne. Jeg har erfareret at diversitet i kompetencer i et team gør at det kan være svært at holde fokus i et 8-timers sprint planlægningsmøde. Det essentielle er at dog at alle kender de overordnede formål, behov og løsningsforslag inden et sprint startes. Der opnås konsensus omkring dette i forbindelse med det korte sprint planlægningsmøde som beskrevet ovenfor
- Der afsættes ikke en dedikeret 8 timers seance hvor fokus udelukkende er på planlægning. Scrum opererer blandt andet med begrebet om timeboxes, alt er sat i en timebox for at undgå spild i form at padlende møder. En måde at bibeholde det i ovenstående tilgang er at lave faste timeboxes til “Product backlog refinement” og på den måde sikre at fokus på minimering af spild bliver fastholdt
Se de øvrige indlæg i “hands-on” serien:
Lige præcis sprint-planlægning er nok der jeg har set størst variation fra team til team. Lige fra teams der fik planen dikteret fra PO’en eller chefen og dermed bare fik forelagt planen på “sprint-planlægnings”-mødet (ca. 10 minutter) til teams der tog både nedbrydning af opgaver, sprint-tema-diskussioner og detaljeret diskussion af hver opgave i et stræk (typisk 4 timer for et 14 dages sprint). Begge yderpunkter fungerede for hvert sit team – med forståelig utilfreds rumlen fra teamet som modtog diktat og forståelig træthed fra teamet som tog de 4 timers diskussion meget alvorligt. God forberedelse til sprintplanlægningen er utroligt vigtigt – og er man tvunget til at tage de lange møder, så sørg for små pauser og snacks.
I SAFe planlægger man en grov skitse for hvert sprint på forhånd for en håndfuld sprints af gangen. Det kan virke meget ufleksibelt, men da planen ikke er sat i sten oplevede jeg det ikke sådan i praksis (hvor rigidt det skal tolkes kan man være ladet afgjort af arbejds-omstændighederne). Tværtimod gav det et godt overblik over visionen at se sprints i en lidt større kontekst – især med hensyn til at forskellige teams skulle arbejde sammen. SAFe er naturligvis til større virksomheder, men at se sprintsne i en større kontekst kan også være rart for mindre teams, hvis de arbejder i et rimeligt robust miljø.
Der findes et hav af måder at afvikle sprint-planlægning. Tak for dine inputs; specielt omkring SAFe og forecasting. Mange Scrum teams savner netop en fastholdelse af vision og fremtidig retning. Det er et emne jeg har tænkt mig at blogge om når jeg får tid igen 🙂