Retrospektivmal: format, eksempel – og hvordan aksjonspunktene overlever til neste retro (2026)

Et retrospektiv er møtet der et team ser på hvordan det jobbet – over en sprint, en release, en måned – og bestemmer hva det skal endre. Ikke hva det bygde, det tar review. Men hvordan det bygde: hva som bremset arbeidet, hva som fikk det til å gå, og hvilke én–to ting teamet skal gjøre annerledes neste gang. En retrospektivmal er den ene siden som holder samtalen i en fast rekkefølge, slik at møtet gir en beslutning i stedet for en liste med klager.

Denne guiden tar håndverket først – formatet, en sprint-retrospektivmal du kan kopiere, et utfylt eksempel og de fire spørsmålssettene de fleste team roterer mellom. Deretter kommer mekanikken: hvor retroen bor i verktøyene teamet allerede bruker, og hva som skjer med aksjonspunktene etter samtalen. For den egentlige testen på et retrospektiv er ikke tavlen ved slutten av timen. Det er de første fem minuttene av det neste, når noen spør om de to endringene alle ble enige om faktisk ble gjennomført.

Hva et retrospektiv er – og hva det ikke er

Fire møter ligger nær retrospektivet, og team slår dem sammen på egen risiko:

Retrospektivet er det eneste av de fire som handler om teamet selv, i teamets nærvær, der teamet bestemmer. Derfor er resultatet lite – et team kan endre én eller to vaner per syklus, ikke ti – og derfor har en retro med lang liste som regel blitt en review eller en hendelsesgjennomgang under feil navn. Agendaen for sprint review og retro-agendaen er to ulike sider av en grunn.

Et retrospektiv er heller ikke et statusmøte med følelser. «La oss gå rundt og si hvordan sprinten føltes» gir en stemning, ikke en endring. Malen nedenfor ber om data før meninger, skriving før snakking og en beslutning før timen er over.

Hva malen inneholder: formatet

En brukbar retrospektivmal har sju deler, i denne rekkefølgen. De fleste maler på nettet er et utvalg av dem, og de to som oftest mangler, er den første og den siste.

1. Forrige retros aksjonspunkter, sjekket. Før alt annet: hvert aksjonspunkt fra sist, eieren, og én av tre tilstander – gjort, ikke gjort med begrunnelse, droppet. To minutter for en liste på tre. Et retrospektiv som hopper over dette punktet, kunngjør at aksjonspunktene er valgfrie, og rommet hører det.
2. Perioden i fakta. Hva som ble levert, hva som skled, hva som gikk i stykker, i tall eller datoer, på tavlen før noen sier noe. Tre til fem linjer. Meninger som diskuteres ut fra de samme faktaene nærmer seg hverandre. Meninger som diskuteres ut fra ulike minner gjør det ikke.
3. Hva som gikk bra. Skriftlig først, én lapp per person per punkt, deretter lest høyt. Å skrive først er regelen som lar den stille halvparten av teamet bli hørt, og den vanlige grunnen til at retroer domineres av to stemmer.
4. Hva som ikke gjorde det. Samme metode. Lappene handler om arbeidet og arbeidsmåten, ikke om personer. Fasilitatoren flytter en lapp som nevner en person, til parkeringsplassen for en én-til-én-samtale.
5. Grupper og velg. Grupper lappene, og la hver person legge to stemmer på gruppene de vil ta tak i. De én–to øverste blir retroens tema for resten av tiden. Resten venter til neste gang, og listen over det som ventet, blir tatt vare på.
6. Én eller to endringer, som aksjonspunkter. For hver valgte gruppe: endringen teamet forplikter seg til, skrevet som et aksjonspunkt: én eier, ett verb, én dato. «Bli flinkere til å estimere» er et ønske. «Lena – legge inn en estimatsjekk på 15 minutter i torsdagens planlegging – fra neste sprint» er et aksjonspunkt.
7. Eiere, en kontrolldato og takk. Les aksjonspunktene opp igjen, med eiere. Si datoen de skal sjekkes, vanligvis neste retro, og avslutt med én runde takk, med navn. Det siste punktet er ikke pynt: det er det som gjør at folk er villige til å skrive lappene i punkt 4 neste gang.

Det som holdes utenfor: alt som hører hjemme i review (omfang), hendelsesgjennomgangen (én feils tidslinje) eller en én-til-én-samtale (én person). Et retrospektiv som prøver å romme dette, går over tid og bestemmer ingenting.

Hvordan gjennomføre ett: før, under, etter

Før: sett av tiden og forbered fakta. Et retrospektiv er et gjentakende møte, etter review og før neste planlegging, slik at det jobber ut fra det som faktisk ble levert. Hvordan det passer inn i uken, står i guiden om møterytme. Dagen før legger fasilitatoren ut periodens fakta i teamets kanal – listen over leverte, listen over utsatte, hendelsene – sammen med forrige retros aksjonspunkter og eiere, slik at punkt 1 og 2 leses før møtet i stedet for å bli satt sammen under det. La fasilitatorrollen gå på rundgang: en retro som lederen styrer hver gang, blir en rapport til lederen.

Under: skriving før snakking, deretter en beslutning. Åpne med sjekken av aksjonspunkter – hver eier sier gjort eller ikke, og hvorfor, i én setning. Så fakta, lest høyt på ett minutt. Så åtte minutter med stille skriving om hva som gikk bra og hva som ikke gjorde det, med hver lapp synlig for alle idet den lander, på hvert medlems eget språk hvis tavlen oversetter, og på det ene språket rommet ble enig om hvis den ikke gjør det. Opplesing, gruppering, stemmer: femten minutter. De valgte gruppene får resten av timen, og fasilitatorens eneste oppgave i den delen er å gjøre snakk om til et aksjonspunkt med et navn før klokken er ute, og lese hvert enkelt opp igjen, slik at eieren sier ja til det to ganger. Fem minutter på slutten: aksjonspunkter med eiere og kontrolldato, deretter takk.

Etter: publiser siden samme dag, der neste retro kommer til å åpne den. Tavlen med lappene, de valgte gruppene, aksjonspunktene med eiere og de forrige aksjonspunktene med tilstandene deres – én side, til alle, også de som ikke var med. Legg den så der neste retrospektiv starter: aksjonssjekken øverst på neste side er en kopi av aksjonslisten nederst på denne. Et retrospektiv som ligger i fasilitatorens notatbok, er et retrospektiv teamet ikke har.

Hvordan selve timen gjennomføres – åpningen, tidsrammene, tilbakeleseren av resultatene de siste fem minuttene – er samme håndverk som ethvert effektivt møte. Det som er spesifikt for retroen, er regelen om å skrive først og grensen på to endringer.

En sprint-retrospektivmal

[Team] – Retrospektiv, sprint [nummer] / [periode]
Dato: [dato] · Tid: [start]–[slutt] · Lenke: [møtelenke]
Formål: velge én eller to endringer i hvordan vi jobber, og sjekke de vi valgte sist.
Fasilitator: [navn, på rundgang] · Referat: [navn eller «oppsummeringen»]
Forhåndslesing: forrige retros side, periodens fakta

1. Forrige retros aksjonspunkter – fasilitator – 5 min – informasjon
– [Eier] – [aksjonspunkt] – frist var [dato] – gjort / ikke gjort: [begrunnelse] / droppet
– [Eier] – [aksjonspunkt] – frist var [dato] – gjort / ikke gjort: [begrunnelse] / droppet

2. Perioden i fakta – fasilitator – 3 min – informasjon
Levert: [liste]. Utsatt: [liste]. Gikk i stykker: [liste]. [Ett tall som betyr noe denne perioden.]

3. Hva som gikk bra – alle, skriftlig først – 8 min – diskusjon
[Lapper, ett punkt hver, lest høyt etter skrivingen.]

4. Hva som ikke gjorde det – alle, skriftlig først – 8 min – diskusjon
[Lapper om arbeidet og arbeidsmåten – ikke om personer.]

5. Grupper og stem – alle – 10 min – beslutning
Grupper: [A], [B], [C]. To stemmer hver. Valgt: [én eller to]. Venter til neste gang: [resten].

6. Endringene vi forplikter oss til – teamet – 15 min – beslutning
– [Eier] – [verb + objekt] – fra [dato] – sjekkes på retroen [dato]
– [Eier] – [verb + objekt] – fra [dato] – sjekkes på retroen [dato]

7. Eiere, kontrolldato, takk – 5 min
Aksjonspunktene leses opp igjen med eiere. Kontrolldato: neste retro, [dato]. Én takk hver, med navn.

Parkeringsplass: [punkter som ble tatt opp, men ikke valgt – tas med til neste retros side]

Malen er ren tekst: den kan limes inn i et dokument, et canvas, en kolonne med post-it-lapper på et whiteboard eller en chatmelding uten omformatering. Rekkefølgen er poenget, ikke verktøyet.

Et utfylt eksempel: et produktteam på åtte etter en sprint på to uker

Plattformteamet – Retrospektiv, sprint 31
Formål: velge én eller to endringer i hvordan vi jobber, og sjekke de vi valgte sist.
Fasilitator: Mateusz · Referat: oppsummeringen
Forhåndslesing: sprint 30s retro-side; fakta for sprint 31, lagt ut i kanalen i går

1. Forrige retros aksjonspunkter – 5 min
– Priya – flytte daily til 09:30 slik at Lisboa kan delta live – frist var 2. nov – gjort
– Kenji – en ensides definition of done for mobilsporet – frist var 6. nov – ikke gjort: venter på endringer fra QA-lederen; ny frist 20. nov

2. Perioden i fakta – 3 min
Leverte 9 av 11 planlagte elementer. Utsatt: eksportjobben, onboarding-e-posten. Gikk i stykker: én hendelse, 40 minutter, søkeindeksen. Reviewen på torsdag gikk 25 minutter over.

3. Hva som gikk bra – 8 min
Parprogrammering på søkefeilen fikk den lukket samme dag. Kanalen tok vare på fakta, så ingen spurte «hva leverte vi» to ganger. Lisboa var med på hver daily.

4. Hva som ikke gjorde det – 8 min
To elementer var halvt spesifisert da sprinten startet. Reviewen gikk over fordi demoen ble satt opp under møtet. Hendelsesrapporten ble skrevet tre dager for sent.

5. Grupper og stem – 10 min
Grupper: klarhet ved sprintstart (6 stemmer), reviewens lengde (4), hendelsesrapporter (3), estimater (2). Valgt: klarhet, reviewen. Venter: hendelsesrapporter, estimater.

6. Endringene vi forplikter oss til – 15 min
– Lena – en klarhetssjekk for hvert element tirsdagen før planlegging; et element uten en spesifikasjon på én linje og en eier kommer ikke inn i sprinten – fra sprint 32 – sjekkes på retroen 28. nov
– Tomás – demomiljøet klart og testet innen kl. 12 på review-dagen – fra sprint 32 – sjekkes på retroen 28. nov

7. Eiere, kontrolldato, takk – 5 min
Lest opp igjen. Kontrolldato: 28. nov. Takk til Priya for søkeparprogrammeringen og til Lisboa for de tidlige starttidene.

Parkeringsplass: hendelsesrapporter; estimater – øverst på listen for sprint 32s retro.

Legg merke til hva som får siden til å fungere: det første punktet og det nest siste er den samme listen sett med to ukers mellomrom. Sprint 31s aksjonspunkter ble født nederst på sprint 30-siden og ble vurdert øverst på denne. Sprint 32s blir vurdert 28. november. Den løkken er hele verdien av et retrospektiv, og det er delen de fleste maler overlater til hukommelsen.

Fire spørsmålssett, og når hvert passer

Punkt 3 og 4 i malen er et par spørsmål, og team blir lei av det samme paret. Fire kjente alternativer, som alle fortsatt ender i punkt 5 og 6:

Uansett hvilket sett du bruker, gjelder to regler: skriving før snakking, og resultatet er ett eller to aksjonspunkter med eiere. Et spørsmålssett som gir en rikere vegg av lapper, men ingen beslutning, har gjort møtet mer interessant og mindre nyttig.

Hvor retrospektivet bor i verktøyene du allerede bruker

Hver av de store plattformene gir retroen en tavle eller et dokument, og hver stopper på et ulikt punkt. Bare dokumentert oppførsel, fra leverandørenes egne sider, med måneden hvert faktum ble sjekket:

To ting er likt i hver rad. Retroens tavle er et dokument ved siden av møtet, på det ene språket den ble skrevet eller holdt på. Og om forrige retros aksjonspunkter ble gjort, er et spørsmål dokumentet ikke besvarer – et menneske åpner forrige side på neste møte og leser den inn i rommet. Der det er greit, duger hvilken som helst av de fire, og tabellen er hele svaret. Hvor transkripsjonen, opptaket og sammendraget av et Teams- eller Meet-anrop havner etterpå, og hvem som fortsatt kan åpne hver av dem, er kartlagt i hvor Teams og Meet lagrer transkripsjon, opptak og sammendrag. Hva hver plattforms direkteoversettelse dekker under samtalen og hvor den stopper, står i Teams- og Meet-guidene (Teams, Meet).

Hvordan aksjonspunktene overlever til neste retro

InterMIND er et kommunikasjonsrom der et møte bor i en kanal, så retrospektivet har et åpenbart hjem: en egen kanal, der periodens fakta og forrige retros aksjonspunkter legges ut dagen før, og der kanalen tar vare på hver økts oppsummering, slik at sprint 30s side er ett klikk unna sprint 31s. Hvert medlem skriver på sitt eget språk og leser de andre på sitt. En side som er skrevet utkast til et annet sted, havner i kanalen på e-post – verten gir kanalen en egen adresse, og en melding sendt dit vises som en vanlig melding med avsenderen navngitt og vedlegg bevart.

Under samtalen er tavlen et notat som legges på alles skjerm ved siden av videorutene med Share to conference: fasilitatoren redigerer det live mens rommet skriver punktene sine, og hver deltaker leser det på sitt eget språk, med originalen ett trykk unna. Forrige økts oppsummering kan deles inn i konferansen på samme måte, slik at punkt 1 – forrige retros aksjonspunkter – er selve protokollen på alles skjerm i stedet for noens erindring av den.

Når samtalen avsluttes, skrives oppsummeringen ut fra selve møtet: et sammendrag, punktene merket som avtalt, åpne eller omstridte, aksjonspunktene med eiere, der hver linje beholder sitt tidsstempel. Den kommer på e-post, som en melding i kanalen og som en lenke i kalenderhendelsen, og hvert innlogget medlem leser den på sitt eget språk – protokollen oversettes per leser, den skrives ikke én gang på språket rommet tilfeldigvis brukte. Alle medlemmer kan redigere den, og hver redigering beholder forfatter og revisjonshistorikk. Verten kan legge til en kopi av oppsummeringen til en hvilken som helst adresse – en innkommende postboks i et oppgavesystem eller CRM – slik at de to aksjonspunktene når systemet som er kilden til sannhet, uten at noen videresender noe. Teams og Meet oversetter, ifølge dokumentasjonen ovenfor, øyeblikket – undertekster i samtalen, en oppsummering på møtets språk. Her er det rommet som forblir oversatt.

I en organisasjon med teamstatussider slått på blir retroens aksjonspunkter også sjekket. Hvert aksjonspunkt en oppsummering registrerer, blir en del av organisasjonens oppgavekjede, og når neste oppsummering skrives, vurderes de åpne mot det som ble sagt: et aksjonspunkt noen rapporterte som ferdig, markeres som gjort; et aksjonspunkt som ble diskutert, men ikke ferdigstilt, markeres som ikke gjort med begrunnelsen i møtets egne ord; et aksjonspunkt ingen tok opp, forblir åpent. Vurderingene bor på organisasjonens statusside, hver med oppsummeringen den bygger på, og ved starten av neste økt nevner Mia de åpne punktene og eierne deres – slik at punkt 1 i malen blir snakket om selv om ingen åpnet forrige side. Teamstatussider er en forhåndsfunksjon: en organisasjons admin slår dem på under Settings → Advanced etter å ha akseptert alfa-vilkårene (siden Preview features beskriver hver enkelt).

En gjest – en konsulent på sprinten, en kundes ingeniør invitert til én retro – blir med via lenke, uten konto og uten kostnad, fra en telefon, i nettleseren, og hører møtet live på sitt eget språk. Det finnes ingen protokoll for en gjest etterpå – kontoen er gratis, og det er den som gjør protokollen tilgjengelig. Verten stiller rommet til rådighet og betaler, på et betalt abonnement, bare for medlemmene som var aktive de siste 28 dagene; medlemmer som blir stille, beholder tilgangen uten kostnad.

• Åpne en komplett oppsummering – en ekte protokoll, gjengitt av den samme koden som skriver din, aksjonspunkter inkludert.
• Prøv live-demoen – uten registrering; snakk, og hør rommet oversatt per lytter.

Retrospektivet som håndverk overlever ethvert verktøy: noen må fortsatt spørre teamet hva som skal endres og holde det til to svar. Det som ikke trenger å overleve, er den andre jobben – å skrive om tavlen etter samtalen, på ett språk, og å åpne neste retro med å spørre om noen gjorde det forrige bestemte.

FAQ

Hva er et retrospektivmøte?

Et retrospektiv er et gjentakende møte der et team ser på hvordan det jobbet over en periode – en sprint, en release, en måned – og forplikter seg til én eller to endringer i arbeidsmåten. Det sjekker først forrige retros aksjonspunkter, legger periodens fakta på tavlen, samler skriftlig hva som gikk bra og hva som ikke gjorde det, grupperer og stemmer, og avsluttes med aksjonspunkter som har en eier og en kontrolldato. Det skiller seg fra review, som ser på hva som ble bygget, og fra en hendelsesgjennomgang, som ser på én feil.

Hvordan gjennomfører man et sprint-retrospektiv?

Sett av tiden etter review og før planlegging, og legg ut periodens fakta og forrige retros aksjonspunkter i teamets kanal dagen før. I møtet: sjekk forrige gangs aksjonspunkter (fem minutter), les fakta, skriv lapper om hva som gikk bra og hva som ikke gjorde det i stillhet før noen snakker, les dem opp, grupper, stem med to stemmer hver, og bruk resten av tiden på å gjøre de én–to øverste gruppene om til aksjonspunkter med én eier og én dato. Les aksjonspunktene opp igjen, si kontrolldatoen – vanligvis neste retro – og avslutt med takk. Publiser siden samme dag der neste retro kommer til å åpne den.

Hva er de 5 stegene i et retrospektiv?

Den mye brukte femtrinnsstrukturen er: sett scenen (formål, de forrige aksjonspunktene, reglene), samle data (periodens fakta og alles lapper), skap innsikt (grupper lappene og finn mønsteret bak dem), bestem hva dere skal gjøre (ett eller to aksjonspunkter med eiere) og avslutt (tilbakelesing, kontrolldato, takk). Malen i denne guiden tilsvarer disse trinnene punkt for punkt: punkt 1–2 setter scenen og samler fakta, 3–5 samler og grupperer, 6 bestemmer, 7 avslutter.

Hva er forskjellen mellom sprint review og sprint-retrospektiv?

Review ser på arbeidet – hva som ble bygget, om det er det som var ment, hva som endres i backloggen – med interessenter i rommet. Retrospektivet ser på arbeidsmåten – hva som bremset teamet og hva det vil endre – med bare teamet til stede. Review etterlater godkjente elementer og endringer i backloggen; retrospektivet etterlater ett eller to aksjonspunkter om hvordan teamet jobber, og forrige gangs aksjonspunkter markert som gjort eller ikke. Retroen kommer etter review slik at den jobber ut fra det som faktisk ble levert.

Hva er start, stop, continue?

Et spørsmålssett for retrospektiv med tre kolonner: hva teamet bør begynne med, hva det bør slutte med, og hva det bør fortsette med. Det erstatter paret «gikk bra» og «gikk ikke bra» i grunnmalen og passer for team som vil ha aksjonspunkter rett fra lappene – en «start»-lapp er allerede halvt et aksjonspunkt. Gruppering, avstemning og grensen på én eller to forpliktede endringer gjelder fortsatt.

Hva er de 4 spørsmålene i et retrospektiv?

Et klassisk retrospektiv stiller fire spørsmål: hva gjorde vi bra, hva lærte vi, hva bør vi gjøre annerledes neste gang, og hva forundrer oss fortsatt. De er de 4L-ene i en annen form – liked, learned, lacked, longed for – og fungerer best over en lengre periode, som et kvartal eller slutten av et prosjekt, der læring betyr like mye som utbedring.

Hvor lenge bør et sprint-retrospektiv vare?

For en sprint på to uker og et team på fem til ti: 45 til 60 minutter – fem til de forrige aksjonspunktene, tre til fakta, seksten til skriving, femten til opplesing, gruppering og stemmer, femten til endringene, fem til avslutning. Et retrospektiv som jevnlig går over tid, har som regel sluppet review eller en hendelsesdiskusjon inn i rommet; en retro som er mye kortere, har som regel hoppet over skrivingen eller aksjonspunktene.

Hva bør en retrospektivmal inneholde?

Sju ting: forrige retros aksjonspunkter med tilstandene deres; perioden i fakta; hva som gikk bra; hva som ikke gjorde det – begge skriftlig først; gruppering og stemmer; én eller to endringer skrevet som aksjonspunkter med en eier og en dato; og avslutningen – tilbakelesing, kontrolldato, takk – med en parkeringsplass for det som ventet. De to delene de fleste maler hopper over, er den første og den nest siste: sjekken av gamle aksjonspunkter og eier-og-dato på de nye. De er det som knytter en retro til den neste.

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 tabellcelle oppgir måneden faktumet ble sjekket: Microsofts notatside, Zooms agendaside, Googles sider og Slacks sider sjekket oktober 2026; Microsofts oppsummeringsside og Zooms side om møtesammendrag sjekket august 2026. Femtrinnsstrukturen og spørsmålssettene er vanlig praksis og bærer ingen leverandørpåstand. Leverandører endrer abonnement, funksjoner og språklister over tid; sjekk sidene deres for gjeldende status.