Mal for sprintplanleggingsagenda for utviklingsteam

Hvorfor sprinter blir overbelastet

Sprintplanlegging har én strukturell svakhet som maler ikke forhindrer: team velger sprint-backlogen før noen sjekker kapasiteten. Resultatet er en sprint som så oppnåelig ut på en tavle og kollapser innen onsdag, når to ingeniører er borte halve uken, én sak tredobler seg i omfang, og tre elementer hadde uuttrykte avhengigheter til en tjeneste plattformteamet holder på å skrive om.

Løsningen er enkel og gjøres nesten aldri: forplikt deg til kapasitet før du forplikter deg til arbeid. Malen under åpner med en kapasitetsgjennomgang av nettopp den grunn.

Agendaen (til å kopiere)

Varighet: 2 timer for en 2-ukers sprint; 1 time for en 1-ukers sprint
Format: Fasilitert, med backlogen synlig for hele teamet

Seksjon 1 — Sprintmål (10 min)

Én setning: hvordan ser en vellykket sprint ut fra utsiden?
Målet bør være spesifikt nok til at ethvert teammedlem kunne vurdere ved sprintslutt om dere traff det
Avvis mål som bare er en liste over saker («fullfør auth-refaktoreringen og faktureringssiden») — det er en backlog, ikke et mål

Seksjon 2 — Kapasitetsgjennomgang (15 min)

List opp hvert teammedlem ved navn
For hver: planlagt ferie, vaktrotasjon, faste møter, kjente eksterne forpliktelser
Uttrykk kapasitet som tilgjengelige story points eller dager — ikke antall hoder
Dette tallet er taket; ikke velg mer arbeid enn det støtter

Seksjon 3 — Backlog-utvelgelse (45 min)

Gå gjennom de høyest prioriterte elementene fra den raffinerte backlogen
For hver kandidat: har teamet nok til å starte det, eller er det åpne spørsmål som trenger svar før sprinten starter? Åpne spørsmål hører hjemme i raffineringskøen, ikke i sprinten
Slutt å velge når dere når 80 % av kapasiteten; de resterende 20 % absorberer overheng og uplanlagt arbeid

Seksjon 4 — Akseptkriterier (20 min)

For hvert valgte element: uttrykk kriteriet som gjør det ferdig
Hvis teamet ikke kan uttrykke et kriterium på 60 sekunder, er saken ikke raffinert nok — flytt den tilbake til backlogen
Skriv det inn i saken nå, i rommet; ikke stol på «vi legger det til senere»

Seksjon 5 — Risikoer og avhengigheter (15 min)

Hva kan blokkere leveringen av sprintmålet som teamet ikke kontrollerer?
Navngi den ansvarlige for avhengigheten; synliggjør den nå mens det er tid til å løse den før midt i sprinten
Uløste avhengigheter får en navngitt ansvarlig fra teamet som skal følge dem opp

Avslutning (15 min)

Bekreft at sprintmålet fortsatt er gyldig gitt det valgte arbeidet
Tildel referenten for sprintoppsummeringen, eller bekreft oppsettet for den automatiske rapporten
Bekreft neste planleggingsdato

Hva de fleste sprintplanleggingsmaler bommer på

De mest populære sprintplanleggingsmalene fokuserer på backlog-raffinering og definition of done. Begge er viktige. Ingen av dem adresserer planleggingsfeilen som produserer flest sprintfeil: å velge arbeid uten å sjekke tilgjengelighet.

Et team på fem ingeniører ved full kapasitet har omtrent 200 story points tilgjengelig per 2-ukers sprint. Et team på fem med to ingeniører på ferie, én på vaktrotasjon og én på et tre dagers samling har kanskje 110. Hvis du velger 180 poeng i den andre sprinten, har du allerede feilet. Utvelgelsessteget er der overforpliktelsen skjer, og kapasitet må komme foran det.

Det andre hullet er akseptkriterier. Team beveger seg raskt gjennom planleggingen og har tenkt å skrive kriteriene senere. Senere skjer ikke på samme detaljnivå. Personen som ville skrevet et presist kriterium i rommet, skriver noe vagere fra hukommelsen dagen etter, eller skriver det ikke i det hele tatt. Uenigheter midt i sprinten om hva «ferdig» betyr, kan nesten alltid spores tilbake til akseptkriterier som ble hoppet over i planleggingen.

Den akkumulerende kostnaden av disse hullene — overbelastede sprinter, oppdagelser midt i sprinten, definisjoner som må reforhandles — viser seg tydelig når du summerer det opp: Møteskatten.

Hvorfor sprintplanleggingsnotater er vanskeligere enn de ser ut

Sprintplanlegging genererer mer informasjon enn nesten noe annet fast møte: sprintmålet, kapasitetstall, begrunnelse for utvelgelse element for element, akseptkriterier per sak, ansvarlige for avhengigheter, risikoelementer. Å skrive en nyttig oppsummering krever å fange opp alt sammen i en form som er nyttig tre dager senere når noen spør «hvorfor kuttet vi det elementet?»

Pavleur genererer sprintplanleggingsrapporten automatisk på slutten av møtet. Den fanger opp sprintmålet, den valgte backlogen med begrunnelse, akseptkriterier slik de ble uttrykt i møtet, og ansvarlige for avhengigheter slik de ble navngitt. Hvis noen delte skjerm med backlogen eller kapasitetsregnearket, er det visuelle inkludert i rapporten ved siden av diskusjonen — kontekst som lyd-baserte verktøy som Otter eller Fireflies ville bommet fullstendig på. Alle som kom sent eller trenger å sjekke en beslutning midt i sprinten, har hele dokumentasjonen. For en sammenligning av hvordan dette skiller seg fra lyd-baserte verktøy: Pavleur vs. alternativene.

Å håndtere planendringer midt i sprinten

Sprintplanen er en forpliktelse, ikke en kontrakt. Når noe midt i sprinten reelt ugyldiggjør planen — en produksjonshendelse, en kritisk avhengighet som blokkerer tre saker, en prioritetsendring fra ledelsen — er den rette responsen en rask omplanleggingssamtale, ikke et stille kutt i omfanget. Omplanleggingssamtalen tar 20 minutter og produserer et oppdatert sprintmål som gjenspeiler virkeligheten. Alternativet er en sprint som feiler på papiret, men som uformelt justeres på måter ingen skrev ned, noe som gjør retrospektiven vanskeligere og velocity-tallene meningsløse.

Bygg vanen med eksplisitt omplanlegging. Bruk samme struktur: oppdatert kapasitet, revidert utvalg, omformulert mål. Det tar langt mindre tid enn forvirringen det forhindrer.