Skabelon til retrospektiv: format, eksempel – og hvordan action items overlever til næste retro (2026)

Et retrospektiv er det møde, hvor et team ser på, hvordan det har arbejdet – over en sprint, en release, en måned – og beslutter, hvad der skal ændres. Ikke hvad det har bygget; det klarer reviewet. Men hvordan det blev bygget: hvad der bremsede arbejdet, hvad der fik det til at glide, og hvilke en eller to ting teamet vil gøre anderledes næste gang. En skabelon til retrospektiv er den ene side, der holder samtalen i en fast rækkefølge, så mødet ender med en beslutning frem for en liste over klager.

Denne guide tager først håndværket – formatet, en skabelon til sprint-retrospektiv, du kan kopiere, et udfyldt eksempel og de fire sæt spørgsmål, de fleste teams skifter mellem – og derefter mekanikken: hvor retroen bor i de værktøjer, dit team allerede bruger, og hvad der sker med dens action items efter mødet. For et retrospektivs egentlige prøve er ikke tavlen ved timens slutning. Det er de første fem minutter af det næste, når nogen spørger, om de to ændringer, alle blev enige om, faktisk blev til noget.

Hvad et retrospektiv er – og hvad det ikke er

Fire møder ligger tæt på retrospektivet, og teams blander dem sammen på egen risiko:

Retrospektivet er det eneste af de fire, der handler om selve teamet, i teamets nærvær, med teamet som beslutningstager. Derfor er dets resultat lille – et team kan ændre en eller to vaner pr. cyklus, ikke ti – og derfor er en retro med en lang liste som regel blevet til et review eller en incident review under forkert navn. Dagsordenen til sprint review og dagsordenen til retroen er to forskellige sider af en grund.

Et retrospektiv er heller ikke et statusmøde med følelser. "Lad os gå rundt og sige, hvordan sprinten føltes" giver et stemningsbillede, ikke en ændring. Skabelonen nedenfor beder om data før meninger, skrivning før snak og en beslutning, før timen er omme.

Hvad skabelonen indeholder: formatet

En brugbar skabelon til retrospektiv har syv dele i denne rækkefølge. De fleste skabeloner på nettet er en delmængde; de to dele, der oftest mangler, er den første og den sidste.

1. Forrige retros action items, tjekket. Før alt andet: hvert action item fra sidst, dets ejer og en af tre tilstande – gennemført, ikke gennemført med begrundelse, droppet. To minutter til en liste på tre. Et retrospektiv, der springer det punkt over, melder ud, at dets action items er valgfrie, og rummet hører det.
2. Perioden i fakta. Hvad der blev leveret, hvad der skred, hvad der gik i stykker, i tal eller datoer, på tavlen, før nogen taler. Tre til fem linjer. Meninger, der diskuteres ud fra de samme fakta, nærmer sig hinanden; meninger, der diskuteres ud fra forskellige erindringer, gør ikke.
3. Hvad der gik godt. Først skriftligt, én seddel pr. person pr. punkt, derefter læst højt. At skrive først er reglen, der lader den stille halvdel af teamet blive hørt, og den almindelige grund til, at retroer domineres af to stemmer.
4. Hvad der ikke gik godt. Samme metode. Sedlerne handler om arbejdet og arbejdsmåden, ikke om personer; facilitatoren flytter en seddel, der nævner en person, til parkeringspladsen til en en-til-en.
5. Gruppér og vælg. Gruppér sedlerne, og lad hver person lægge to stemmer på de grupper, de vil have behandlet. De øverste en eller to bliver retroens emne i den resterende tid; resten venter til næste gang, og listen over det, der ventede, gemmes.
6. En eller to ændringer som action items. For hver valgt gruppe skrives den ændring, teamet forpligter sig til, som et action item: én ejer, ét verbum, én dato. "Bliv bedre til at estimere" er et ønske; "Lena – tilføj et 15 minutters estimat-tjek til torsdagens planlægning – fra næste sprint" er et action item.
7. Ejere, en kontroldato og anerkendelse. Læs action items op igen med ejere; nævn datoen, de tjekkes – normalt næste retro – og afslut med en runde tak, med navns nævnelse. Det sidste punkt er ikke pynt: det er det, der gør folk villige til at skrive sedlerne i punkt 4 næste gang.

Det, der holdes ude: alt, der hører hjemme i reviewet (scope), incident reviewet (én fejls tidslinje) eller en en-til-en (én person). Et retrospektiv, der forsøger at rumme det, løber over tid og beslutter intet.

Sådan afvikler du et: før, under, efter

Før: fastlæg tidspunktet og forbered fakta. Et retrospektiv er et tilbagevendende møde, efter reviewet og før næste planlægning, så det arbejder ud fra det, der faktisk blev leveret. Hvordan det passer ind i ugen, står i guiden til mødekadence. Dagen før lægger facilitatoren periodens fakta op i teamets kanal – listen over det leverede, listen over det forsinkede, hændelserne – og sidste retros action items med ejere, så punkt 1 og punkt 2 er læst inden mødet, ikke samlet under det. Rotér facilitatoren: en retro, der hver gang ledes af lederen, bliver til en rapport til lederen.

Under: skriv før snak, derefter en beslutning. Åbn med tjekket af action items – hver ejer siger gennemført eller ej, og hvorfor, i én sætning. Derefter fakta, læst højt på et minut. Derefter otte minutters stille skrivning om det gode og det mindre gode, hver seddel synlig for alle, idet den lander, på hvert medlems eget sprog, hvis tavlen oversætter, og på det ene sprog, rummet er enedes om, hvis den ikke gør. Oplæsning, gruppering, afstemning: femten minutter. De valgte grupper får resten af timen, og facilitatorens ene opgave i den periode er at gøre snak til et action item med et navn på, før uret løber ud, og læse hvert enkelt op igen, så ejeren siger ja to gange. Fem minutter til sidst: action items med ejere og kontroldatoen, derefter anerkendelse.

Efter: udgiv siden samme dag, der hvor næste retro vil åbne den. Tavlen med sine sedler, de valgte grupper, action items med ejere og de forrige action items med deres tilstande – én side, til alle, også dem, der var forhindret. Læg den derefter, hvor næste retrospektiv starter: tjekket af action items øverst på næste side er en kopi af listen med action items nederst på denne. Et retrospektiv, der ligger i facilitatorens notesbog, er et retrospektiv, teamet ikke har.

Hvordan selve timen afvikles – åbningen, tidsrammerne, oplæsningen af resultaterne de sidste fem minutter – er samme håndværk som ethvert effektivt møde. Det, der er særligt for retroen, er reglen om at skrive først og grænsen på to ændringer.

En skabelon til sprint-retrospektiv

[Team] — Retrospektiv, sprint [nummer] / [periode]
Dato: [dato] · Tid: [start]–[slut] · Link: [mødelink]
Formål: vælge en eller to ændringer i, hvordan vi arbejder, og tjekke dem, vi valgte sidst.
Facilitator: [navn, roterende] · Referat: [navn eller "recap'en"]
Læses inden: sidste retros side, periodens fakta

1. Sidste retros action items — facilitator — 5 min — information
– [Ejer] — [action item] — skulle være færdigt [dato] — gennemført / ikke gennemført: [begrundelse] / droppet
– [Ejer] — [action item] — skulle være færdigt [dato] — gennemført / ikke gennemført: [begrundelse] / droppet

2. Perioden i fakta — facilitator — 3 min — information
Leveret: [liste]. Forsinket: [liste]. Gik i stykker: [liste]. [Ét tal, der har betydning i denne periode.]

3. Hvad der gik godt — alle, først skriftligt — 8 min — diskussion
[Sedler, ét punkt hver, læst højt efter skrivningen.]

4. Hvad der ikke gik godt — alle, først skriftligt — 8 min — diskussion
[Sedler om arbejdet og arbejdsmåden – ikke om personer.]

5. Gruppér og stem — alle — 10 min — beslutning
Grupper: [A], [B], [C]. To stemmer hver. Valgt: [en eller to]. Venter til næste gang: [resten].

6. De ændringer, vi forpligter os til — teamet — 15 min — beslutning
– [Ejer] — [verbum + objekt] — fra [dato] — tjekkes på retroen den [dato]
– [Ejer] — [verbum + objekt] — fra [dato] — tjekkes på retroen den [dato]

7. Ejere, kontroldato, anerkendelse — 5 min
Action items læst op med ejere. Kontroldato: næste retro, [dato]. En tak hver, med navns nævnelse.

Parkeringsplads: [punkter, der blev rejst men ikke valgt – overføres til næste retros side]

Skabelonen er ren tekst: den kan sættes ind i et dokument, et canvas, en kolonne med sticky notes på et whiteboard eller en chatbesked uden omformatering. Rækkefølgen er pointen; værktøjet er det ikke.

Et udfyldt eksempel: et produktteam på otte efter en sprint på to uger

Platformsteamet — Retrospektiv, sprint 31
Formål: vælge en eller to ændringer i, hvordan vi arbejder, og tjekke dem, vi valgte sidst.
Facilitator: Mateusz · Referat: recap'en
Læses inden: sprint 30's retro-side; sprint 31's fakta, lagt i kanalen i går

1. Sidste retros action items — 5 min
– Priya — flyt daily til 09:30, så Lissabon kan deltage live — skulle være færdigt 2. nov. — gennemført
– Kenji — en definition of done på én side for mobilsporet — skulle være færdigt 6. nov. — ikke gennemført: venter på QA-lederens rettelser; ny dato 20. nov.

2. Perioden i fakta — 3 min
Leveret 9 af 11 planlagte punkter. Forsinket: eksportjobbet, onboarding-mailen. Gik i stykker: én hændelse, 40 minutter, søgeindekset. Torsdagens review løb 25 minutter over.

3. Hvad der gik godt — 8 min
Parprogrammering på søgefejlen fik den lukket samme dag. Kanalen holdt på fakta, så ingen spurgte to gange "hvad leverede vi". Lissabon deltog i hver daily.

4. Hvad der ikke gik godt — 8 min
To punkter var kun halvt specificeret, da sprinten startede. Reviewet løb over, fordi demoen blev sat op under mødet. Hændelsesrapporten blev skrevet tre dage for sent.

5. Gruppér og stem — 10 min
Grupper: parathed ved sprintstart (6 stemmer), reviewets længde (4), hændelsesrapporter (3), estimater (2). Valgt: parathed, reviewet. Venter: hændelsesrapporter, estimater.

6. De ændringer, vi forpligter os til — 15 min
– Lena — et parathedstjek af hvert punkt tirsdagen før planlægning; et punkt uden en specifikation på én linje og en ejer kommer ikke med i sprinten — fra sprint 32 — tjekkes på retroen den 28. nov.
– Tomás — demomiljøet klart og testet inden kl. 12 på reviewdagen — fra sprint 32 — tjekkes på retroen den 28. nov.

7. Ejere, kontroldato, anerkendelse — 5 min
Læst op. Kontroldato: 28. nov. Tak til Priya for parprogrammeringen på søgningen og til Lissabon for de tidlige starter.

Parkeringsplads: hændelsesrapporter; estimater — øverst på listen til sprint 32's retro.

Læg mærke til, hvad der får siden til at virke: det første punkt og det næstsidste er den samme liste set med to ugers mellemrum. Sprint 31's action items blev født nederst på sprint 30's side og blev bedømt øverst på denne; sprint 32's bliver bedømt den 28. november. Den løkke er hele værdien af et retrospektiv, og det er den del, de fleste skabeloner overlader til hukommelsen.

Fire sæt spørgsmål, og hvornår hvert passer

Punkt 3 og 4 i skabelonen er et par spørgsmål, og teams bliver trætte af det samme par. Fire velkendte alternativer, der alle stadig ender i punkt 5 og 6:

Uanset hvilket sæt du bruger, gælder to regler: skrivning før snak, og resultatet er et eller to action items med ejere. Et sæt spørgsmål, der giver en rigere væg af sedler, men ingen beslutning, har gjort mødet mere interessant og mindre nyttigt.

Hvor retrospektivet bor i de værktøjer, du allerede bruger

Hver større platform giver retroen en tavle eller et dokument, og hver stopper et forskelligt sted. Kun dokumenteret adfærd, fra leverandørernes egne sider, med den måned, hvert forhold blev tjekket:

To ting er ens i alle rækker. Retroens tavle er et dokument ved siden af mødet, på det ene sprog, den blev skrevet eller holdt på; og om sidste retros action items blev gennemført, er et spørgsmål, dokumentet ikke besvarer – en person åbner den forrige side på næste møde og læser den op for rummet. Hvor det er fint, duer enhver af de fire, og tabellen er hele svaret. Hvor transskription, optagelse og resumé af et Teams- eller Meet-opkald havner bagefter, og hvem der stadig kan åbne hver af dem, er kortlagt i hvor Teams og Meet gemmer din transskription, optagelse og dit resumé. Hvad hver platforms live-oversættelse dækker i selve opkaldet, og hvor den stopper, står i guiderne til Teams og Meet (Teams, Meet).

Sådan overlever action items til næste retro

InterMIND er et kommunikationsrum, hvor et møde lever i en kanal, så retrospektivet har et oplagt hjem: en kanal for sig, hvor periodens fakta og sidste retros action items lægges op dagen før, og hvor kanalen gemmer hver sessions recap, så sprint 30's side er ét klik fra sprint 31's. Hvert medlem skriver på sit eget sprog og læser de andre på sit; en side, der er skrevet et andet sted, lander i kanalen via e-mail – værten giver kanalen en adresse for sig selv, og en besked sendt til den vises som en almindelig besked med afsenderen nævnt og vedhæftede filer bevaret.

Under opkaldet er tavlen en note, der vises på alles skærm ved siden af videofelterne med Share to conference: facilitatoren redigerer den live, mens rummet skriver sine punkter, og hver deltager læser den på sit eget sprog, med originalen ét tryk væk. Den forrige sessions recap kan deles ind i konferencen på samme måde, så punkt 1 – sidste retros action items – er den faktiske optegnelse på alles skærm i stedet for nogens erindring om den.

Når opkaldet slutter, skrives recap'en ud fra selve mødet: et resumé, punkterne markeret som aftalt, åbne eller omstridte, og action items med ejere, hver linje med sit tidsstempel. Den kommer på e-mail, som en besked i kanalen og som et link i kalenderbegivenheden, og hvert logget ind medlem læser den på sit eget sprog – optegnelsen oversættes pr. læser og skrives ikke én gang på det sprog, rummet tilfældigvis brugte. Ethvert medlem kan redigere den, og hver redigering bevarer forfatter og versionshistorik. Værten kan tilføje en kopi af recap'en til en hvilken som helst adresse – en tracker eller en CRM-indbakke – så de to action items når frem til systemet, hvor de skal ligge, uden at nogen videresender noget. Teams og Meet oversætter ifølge deres dokumentation ovenfor øjeblikket – undertekster i opkaldet, en recap på mødets sprog; her er det rummet, der forbliver oversat.

I en organisation med team-statussider slået til bliver retroens action items også tjekket. Hvert action item, en recap registrerer, indgår i organisationens opgavekæde, og når den næste recap skrives, vurderes de åbne ud fra det, der blev sagt: et action item, nogen meldte færdigt, markeres som gennemført; et action item, der blev drøftet men ikke blev færdigt, markeres som ikke gennemført med begrundelsen i mødets egne ord; et action item, ingen tog op, forbliver åbent. Vurderingerne ligger på organisationens statusside, hver med den recap, den bygger på, og ved starten af næste session nævner Mia de åbne punkter og deres ejere – så punkt 1 i skabelonen bliver talt om, selv når ingen åbnede den forrige side. Team-statussider er en preview-funktion: en organisations admin slår dem til under Settings → Advanced efter at have accepteret alfa-vilkårene (siden Preview features beskriver hver enkelt).

En gæst – en freelancer på sprinten, en kundes ingeniør inviteret til én retro – deltager via link, uden konto og uden omkostning, fra en telefon eller i browseren, og hører mødet live på sit eget sprog. Der er ingen optegnelse til en gæst bagefter – kontoen er gratis, og det er den, der gør optegnelsen tilgængelig. Værten stiller rummet til rådighed og betaler på en betalt plan kun for medlemmer, der har været aktive de seneste 28 dage; medlemmer, der bliver stille, beholder deres adgang uden omkostning.

• Åbn en komplet recap — en ægte optegnelse, gengivet af den samme kode, der skriver din, action items inkluderet.
• Prøv live-demoen — uden tilmelding; tal, og hør rummet oversat pr. lytter.

Retrospektivet som håndværk overlever ethvert værktøj: nogen skal stadig spørge teamet, hvad der skal ændres, og holde det fast på to svar. Det, der ikke behøver at overleve, er det andet job – at skrive tavlen af igen efter opkaldet, på ét sprog, og åbne næste retro med at spørge, om nogen gjorde det, den forrige besluttede.

FAQ

Hvad er et retrospektivmøde?

Et retrospektiv er et tilbagevendende møde, hvor et team ser på, hvordan det har arbejdet over en periode – en sprint, en release, en måned – og forpligter sig til en eller to ændringer i sin arbejdsmåde. Det tjekker først forrige retros action items, lægger periodens fakta på tavlen, samler hvad der gik godt, og hvad der ikke gjorde, skriftligt, grupperer og stemmer og ender med action items, der har en ejer og en kontroldato. Det adskiller sig fra reviewet, som ser på det, der blev bygget, og fra en incident review, som ser på én fejl.

Hvordan afvikler man et sprint-retrospektiv?

Fastlæg tidspunktet efter reviewet og før planlægningen, og læg periodens fakta og sidste retros action items op i teamets kanal dagen før. På mødet: tjek sidste gangs action items (fem minutter), læs fakta op, skriv sedler om det gode og det mindre gode i stilhed, før nogen taler, læs dem op, gruppér, stem med to stemmer hver, og brug den resterende tid på at gøre de øverste en eller to grupper til action items med én ejer og én dato. Læs action items op igen, nævn kontroldatoen – normalt næste retro – og afslut med anerkendelse. Udgiv siden samme dag, der hvor næste retro vil åbne den.

Hvad er de 5 faser i et retrospektiv?

Den udbredte femtrinsstruktur er: sæt scenen (formål, de forrige action items, spillereglerne), indsaml data (periodens fakta og alles sedler), skab indsigt (gruppér sedlerne og find mønstret bag dem), beslut, hvad der skal gøres (en eller to action items med ejere), og afslut (oplæsning, kontroldato, anerkendelse). Skabelonen i denne guide svarer til de faser punkt for punkt: punkt 1–2 sætter scenen og indsamler fakta, 3–5 indsamler og grupperer, 6 beslutter, 7 afslutter.

Hvad er forskellen på en sprint review og et sprint-retrospektiv?

Reviewet ser på arbejdet – hvad der blev bygget, om det er det, der var meningen, hvad der ændrer sig i backloggen – med interessenter i rummet. Retrospektivet ser på arbejdsmåden – hvad der bremsede teamet, og hvad det vil ændre – kun med teamet. Reviewet efterlader godkendte punkter og ændringer i backloggen; retrospektivet efterlader en eller to action items om, hvordan teamet arbejder, og sidste gangs action items markeret som gennemført eller ej. Retroen ligger efter reviewet, så den arbejder ud fra det, der faktisk blev leveret.

Hvad er start, stop, continue?

Et sæt spørgsmål til retrospektiver med tre kolonner: hvad teamet bør starte med, hvad det bør stoppe med, og hvad det bør fortsætte med. Det erstatter parret "gik godt / gik ikke godt" i den grundlæggende skabelon og passer til teams, der vil have action items direkte fra sedlerne – en "start"-seddel er allerede et halvt action item. Gruppering, afstemning og grænsen på en eller to forpligtede ændringer gælder stadig.

Hvad er de 4 spørgsmål i et retrospektiv?

Et klassisk retrospektiv stiller fire spørgsmål: hvad gjorde vi godt, hvad lærte vi, hvad bør vi gøre anderledes næste gang, og hvad undrer vi os stadig over. Det er 4L'erne i en anden form – liked, learned, lacked, longed for – og de virker bedst over en længere periode, som et kvartal eller afslutningen af et projekt, hvor læring betyder lige så meget som at rette fejl.

Hvor længe bør et sprint-retrospektiv vare?

For en sprint på to uger og et team på fem til ti: 45 til 60 minutter – fem til de forrige action items, tre til fakta, seksten til skrivning, femten til oplæsning, gruppering og afstemning, femten til ændringerne, fem til afslutning. En retro, der jævnligt løber længere, har som regel lukket reviewet eller en diskussion om en hændelse ind i rummet; en retro, der er meget kortere, har som regel sprunget skrivningen eller action items over.

Hvad bør en skabelon til retrospektiv indeholde?

Syv ting: forrige retros action items med deres tilstande; perioden i fakta; hvad der gik godt; hvad der ikke gik godt – begge først skriftligt; gruppering og afstemning; en eller to ændringer skrevet som action items med en ejer og en dato; og afslutningen – oplæsning, kontroldato, anerkendelse – med en parkeringsplads til det, der ventede. De to dele, de fleste skabeloner springer over, er den første og den næstsidste: tjekket af gamle action items og ejer-og-dato på de nye. Det er dem, der forbinder én retro med den næste.

Kilder: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Generating meeting agenda with AI Companion; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template; Slack — Use huddles in Slack. Hver tabelcelle nævner den måned, dens forhold blev tjekket: Microsofts side om noter, Zooms side om dagsordener, Googles sider og Slacks sider tjekket oktober 2026; Microsofts recap-side og Zooms side om mødeopsummering tjekket august 2026. Femtrinsstrukturen og spørgsmålssættene er almindelig praksis og bærer ingen leverandørpåstand. Leverandører ændrer planer, funktioner og sproglister over tid; tjek deres sider for den aktuelle tilstand.