
Hvad der hører til i en sprint planning-skabelon: mål, kapacitet, ejere, definition of done og risici. Og hvorfor kapaciteten kommer først.
Sprint planning er der, hvor en backlog bliver til en forpligtelse. En skabelon forhindrer, at mødet producerer en vag liste, som ingen har holdt op mod de timer, teamet faktisk har.
Kort svar: En sprint planning-skabelon er en fast struktur, du udfylder under planlægningen: sprintmålet, teamets reelle kapacitet, de valgte punkter med én ejer og ét estimat hver, definition of done og de risici, I accepterer. Udfyld kapaciteten, før I vælger arbejde. Den ene vane gør sprintplanen til noget, teamet kan gøre færdigt, i stedet for en ønskeliste.
En sprint planning-skabelon er de samme fem spørgsmål i starten af hver sprint, i samme rækkefølge. Værdien ligger ikke i formateringen, men i at spørgsmålene overhovedet bliver stillet. Teams springer kapaciteten over, fordi den er ubehagelig, ejere fordi tildeling føles bureaukratisk, og risici fordi det føles negativt at nævne dem. To uger senere er sprinten forsinket af præcis de grunde.
Fem felter dækker, hvad en sprint har brug for for at være reel. Har din skabelon femten, er de ti ekstra grunden til, at ingen udfylder den.

Skabelonen deler mødet op i før, under og efter, og det er i før-delen, tiden vindes.
Sprintplaner forældes, fordi de bor i et dokument, og sprinten sker et andet sted. Planen var sand mandag morgen; onsdag er to punkter vokset, én er gået syg hjem, og dokumentet viser stadig mandagsversionen. Ingen opdaterer det, fordi en opdatering ikke ændrer noget: Dokumentet kender hverken teamets dage eller deadlines.
Løsningen er strukturel: Hold planen der, hvor datoerne og ejerne bor, så en ændring i planen ændrer nogens uge. En plan hvis trin ligger på rigtige kalenderdage, med en rigtig person på hvert trin, bliver rettet som en sideeffekt af, at folk laver arbejdet.

Tre artefakter, tre horisonter
|Artefakt|Horisont|Hvad den svarer på|
|---|---|---|
|Sprintplan|Én sprint|Hvad bliver vi færdige med, hvem gør hvad, hvor meget er der plads til|
|Sprint backlog|Én sprint, live|Hvad er der tilbage lige nu, i hvilken rækkefølge|
|Roadmap|Kvartaler|Hvor er produktet på vej hen, cirka hvornår|
Sprintplanen er øjebliksbilledet, teamet forpligter sig på; backloggen er den levende liste, der tømmes i løbet af sprinten; roadmappet er den lange linje, sprintene lægger sig sammen til. En god handlingsplan deler sprintplanens anatomi, og til alt der varer længere end et par sprints bygger du i virkeligheden en projekttidsplan.
Ja, hvis du beskriver sprinten i stedet for at lede efter en skabelon. I SketchMind, et AI-whiteboard, har Plans med vilje ingen færdig sprintskabelon: Du trykker på "+ New plan", vælger formen (Phases, Weeks eller Milestones) og beskriver sprinten i feltet "Describe it · AI drafts the plan": hvad I bygger, for hvem, til hvornår, med hvem. Du kan indsætte en brief eller vedhæfte en PDF på op til 25 MB. AI'en spørger kun om det, der mangler (omfang, personer, timing, begrænsninger, hvad succes betyder), og skriver så planen: trin med datoer og ejere, en kort begrundelse pr. trin og risici med, hvad I gør ved dem. Hvert trin lander på sin ejers agenda, og når virkeligheden skrider, siger planen det: "Running 3 days late" kommer med "Move the plan 3 days" eller "I'll catch up", så planen flytter sig i stedet for at rådne i stilhed. Kapacitetsbeslutningen og det endelige omfang er stadig dine; skrivningen og datoflytningen holder op med at koste en eftermiddag.
Senest opdateret: 8. oktober 2026. Tjekket mod den aktuelle SketchMind-app.
Sprintplanen er øjebliksbilledet, teamet forpligter sig på ved planlægningen: mål, kapacitet, punkter med ejere. Sprint backloggen er den levende liste, der ændrer sig i løbet af sprinten, mens arbejde bliver færdigt, og virkeligheden blander sig.
En almindelig tommelfingerregel er cirka en time pr. sprintuge, altså to timer for en to-ugers sprint. Tager det meget længere, var det forberedelsen, der manglede, ikke tiden.
Gang personer med arbejdsdage, og træk så alt fra, som kalenderen allerede gør krav på: ferie, samtaler, supportvagt, faste møder. Resten er det, I planlægger op imod.
Én sætning der beskriver en tilstand, ikke en liste af tickets: "Nye brugere gennemfører onboardingen uden hjælp." Hvert kandidatpunkt kan testes mod den.
Nej, og det er med vilje. I Plans beskriver du din sprint, og AI'en skriver den som faser eller uger med trin, datoer og ejere; AI'en spørger om det, der mangler, i stedet for at give dig tomme felter.