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:

• https://qed.dk/rasmus-kaae/tag/hands-on/