Retrospektivmall: format, exempel – och hur åtgärdspunkter överlever till nästa retro (2026)

Ett retrospektiv är mötet där ett team tittar på hur det arbetade – under en sprint, en release, en månad – och bestämmer vad som ska ändras. Det handlar inte om vad teamet byggde, det tar granskningen hand om. Det handlar om hur det byggdes: vad som bromsade arbetet, vad som fick det att flyta och vilka en eller två saker teamet ska göra annorlunda nästa gång. En retrospektivmall är den sida som håller samtalet i en fast ordning, så att mötet ger ett beslut i stället för en lista med klagomål.

Den här guiden tar först hantverket – formatet, en mall för sprintretrospektiv som du kan kopiera, ett ifyllt exempel och de fyra uppsättningar frågor som de flesta team roterar mellan. Sedan går den igenom mekaniken: var retron bor i de verktyg som ditt team redan använder och vad som händer med dess åtgärder efter samtalet. För ett retrospektivs verkliga prov är inte tavlan i slutet av timmen. Det är de första fem minuterna av nästa, när någon frågar om de två förändringarna som alla var överens om faktiskt blev av.

Vad ett retrospektiv är – och vad det inte är

Fyra möten ligger nära retrospektivet, och team slår ihop dem på egen bekostnad:

Retrospektivet är det enda av de fyra som handlar om teamet självt, i teamets närvaro, där teamet fattar besluten. Därför är resultatet litet – ett team kan ändra en eller två vanor per cykel, inte tio – och därför har en retro med lång lista oftast blivit en granskning eller en incidentgranskning under fel namn. Dagordningen för sprintgranskningen och retrons dagordning är två olika sidor av en anledning.

Ett retrospektiv är inte heller ett statusmöte med känslor. ”Nu tar vi en runda och säger hur sprinten kändes” ger ett stämningsläge, inte en förändring. Mallen nedan ber om data före åsikter, skrivande före pratande och ett beslut innan timmen är slut.

Vad mallen innehåller: formatet

En användbar retrospektivmall har sju delar, i den här ordningen. De flesta mallar på nätet är en delmängd, och de två som oftast saknas är den första och den sista.

1. Förra retrons åtgärder, avprickade. Före allt annat: varje åtgärd från förra gången, dess ansvariga och ett av tre lägen – klar, inte klar med orsak, avskriven. Två minuter för en lista med tre. Ett retrospektiv som hoppar över den här punkten förklarar att dess åtgärder är frivilliga, och rummet hör det.
2. Perioden i fakta. Vad som levererades, vad som försenades, vad som gick sönder, i siffror eller datum, på tavlan innan någon pratar. Tre till fem rader. Åsikter som diskuteras utifrån samma fakta konvergerar; åsikter som diskuteras utifrån olika minnen gör det inte.
3. Vad som gick bra. Först skriftligt, en lapp per person och punkt, sedan uppläst. Att skriva först är regeln som låter den tysta halvan av teamet höras, och den vanliga orsaken till att retron domineras av två röster.
4. Vad som inte gick bra. Samma metod. Lapparna handlar om arbetet och arbetssättet, inte om personer; facilitatorn flyttar en lapp som nämner en person till parkeringsplatsen för ett enskilt samtal.
5. Gruppera och välj. Klustra lapparna och låt var och en lägga två röster på de kluster som ska tas upp. De ett eller två översta blir retrons ämne under resten av tiden; resten får vänta till nästa gång, och listan över vad som väntade sparas.
6. En eller två förändringar, som åtgärder. För varje valt kluster skriver man den förändring teamet förbinder sig till som en åtgärdspunkt: en ansvarig, ett verb, ett datum. ”Bli bättre på att uppskatta” är en förhoppning; ”Lena – lägg in en 15 minuters uppskattningskontroll i torsdagens planering – från nästa sprint” är en åtgärd.
7. Ansvariga, kontrolldatum och uppskattning. Läs upp åtgärderna med ansvariga; nämn datumet då de kontrolleras – normalt nästa retro; och avsluta med en runda tack, med namn. Den sista punkten är ingen dekoration: den gör att folk är villiga att skriva lapparna i punkt 4 nästa gång.

Det som lämnas utanför: allt som hör hemma i granskningen (omfattning), incidentgranskningen (ett felfalls tidslinje) eller ett enskilt samtal (en person). Ett retrospektiv som försöker rymma sådant drar över tiden och bestämmer ingenting.

Så genomför du ett: före, under, efter

Före: lås tiden och förbered fakta. Ett retrospektiv är ett återkommande möte, efter granskningen och före nästa planering, så att det utgår från det som faktiskt levererades; hur det sitter i veckan finns i guiden om mötesrytm. Dagen innan lägger facilitatorn upp periodens fakta i teamets kanal – listan över det levererade, listan över det försenade, incidenterna – och förra retrons åtgärder med ansvariga, så att punkt 1 och punkt 2 läses före mötet och inte sammanställs under det. Rotera facilitatorn: en retro som chefen leder varje gång blir en rapport till chefen.

Under: skriva före prata, sedan ett beslut. Börja med åtgärdskontrollen – varje ansvarig säger klart eller inte, och varför, i en mening. Sedan fakta, uppläst på en minut. Sedan åtta minuters tyst skrivande om vad som gick bra och vad som inte gjorde det, med varje lapp synlig för alla när den landar, på varje medlems eget språk om tavlan översätter och på det enda språk rummet kommit överens om om den inte gör det. Uppläsning, klustring, röstning: femton minuter. De valda klustren får resten av timmen, och facilitatorns enda uppgift under den delen är att göra prat till en åtgärd med ett namn innan klockan har gått ut, och läsa upp varje åtgärd så att den ansvariga godkänner den två gånger. Fem minuter i slutet: åtgärder med ansvariga och kontrolldatum, sedan uppskattning.

Efter: publicera sidan samma dag, där nästa retro kommer att öppna den. Tavlan med sina lappar, de valda klustren, åtgärderna med ansvariga och de tidigare åtgärderna med sina lägen – en sida, till alla, även den som missade mötet. Lägg den sedan där nästa retrospektiv börjar: åtgärdskontrollen överst på nästa sida är en kopia av åtgärdslistan längst ned på den här. Ett retrospektiv som ligger i facilitatorns anteckningsbok är ett retrospektiv som teamet inte har.

Hur själva timmen leds – öppningen, tidsramarna, uppläsningen av resultaten under de sista fem minuterna – är samma hantverk som i vilket effektivt möte som helst. Det som är specifikt för retron är regeln att skriva först och gränsen på två förändringar.

En mall för sprintretrospektiv

[Team] – Retrospektiv, sprint [nummer] / [period]
Datum: [datum] · Tid: [start]–[slut] · Länk: [mötеslänk]
Syfte: välja en eller två förändringar i hur vi arbetar och kontrollera dem vi valde förra gången.
Facilitator: [namn, roterande] · Anteckningar: [namn eller ”recapen”]
Förberedelse: förra retrons sida, periodens fakta

1. Förra retrons åtgärder – facilitator – 5 min – information
– [Ansvarig] – [åtgärd] – skulle vara klar [datum] – klar / inte klar: [orsak] / avskriven
– [Ansvarig] – [åtgärd] – skulle vara klar [datum] – klar / inte klar: [orsak] / avskriven

2. Perioden i fakta – facilitator – 3 min – information
Levererat: [lista]. Försenat: [lista]. Gick sönder: [lista]. [Ett tal som spelar roll den här perioden.]

3. Vad som gick bra – alla, skriftligt först – 8 min – diskussion
[Lappar, en punkt var, upplästa efter skrivandet.]

4. Vad som inte gick bra – alla, skriftligt först – 8 min – diskussion
[Lappar om arbetet och arbetssättet – inte om personer.]

5. Gruppera och rösta – alla – 10 min – beslut
Kluster: [A], [B], [C]. Två röster var. Valda: [ett eller två]. Väntar till nästa gång: [resten].

6. Förändringarna vi förbinder oss till – teamet – 15 min – beslut
– [Ansvarig] – [verb + objekt] – från [datum] – kontrolleras på retron den [datum]
– [Ansvarig] – [verb + objekt] – från [datum] – kontrolleras på retron den [datum]

7. Ansvariga, kontrolldatum, uppskattning – 5 min
Åtgärderna upplästa med ansvariga. Kontrolldatum: nästa retro, [datum]. Ett tack var, med namn.

Parkeringsplats: [punkter som togs upp men inte valdes – förs över till nästa retros sida]

Mallen är ren text: den går att klistra in i ett dokument, en canvas, en whiteboardkolumn med klisterlappar eller ett chattmeddelande utan omformatering. Ordningen är poängen, inte verktyget.

Ett ifyllt exempel: ett produktteam på åtta efter en tvåveckorssprint

Plattformsteamet – Retrospektiv, sprint 31
Syfte: välja en eller två förändringar i hur vi arbetar och kontrollera dem vi valde förra gången.
Facilitator: Mateusz · Anteckningar: recapen
Förberedelse: sprint 30:s retrosida; fakta för sprint 31 som lades upp i kanalen i går

1. Förra retrons åtgärder – 5 min
– Priya – flytta daily till 09.30 så att Lissabon kan delta live – skulle vara klar 2 nov – klar
– Kenji – en sida med definition of done för mobilspåret – skulle vara klar 6 nov – inte klar: väntar på QA-ansvarigas ändringar; nytt datum 20 nov

2. Perioden i fakta – 3 min
Levererade 9 av 11 planerade punkter. Försenat: exportjobbet, onboardingmejlet. Gick sönder: en incident, 40 minuter, sökindexet. Granskningen på torsdagen drog över med 25 minuter.

3. Vad som gick bra – 8 min
Parprogrammeringen på sökfelet gjorde att det stängdes samma dag. Kanalen höll kvar fakta, så ingen frågade ”vad levererade vi” två gånger. Lissabon deltog i varje daily.

4. Vad som inte gick bra – 8 min
Två punkter var halvspecificerade när sprinten startade. Granskningen drog över eftersom demon ställdes i ordning under mötet. Incidentrapporten skrevs tre dagar för sent.

5. Gruppera och rösta – 10 min
Kluster: beredskap vid sprintstart (6 röster), granskningens längd (4), incidentrapporter (3), uppskattningar (2). Valda: beredskap, granskningen. Väntar: incidentrapporter, uppskattningar.

6. Förändringarna vi förbinder oss till – 15 min
– Lena – en beredskapskontroll för varje punkt tisdagen före planeringen; en punkt utan en rads specifikation och en ansvarig kommer inte in i sprinten – från sprint 32 – kontrolleras på retron den 28 nov
– Tomás – demomiljön klar och testad senast klockan 12 på granskningsdagen – från sprint 32 – kontrolleras på retron den 28 nov

7. Ansvariga, kontrolldatum, uppskattning – 5 min
Uppläst. Kontrolldatum: 28 nov. Tack till Priya för parprogrammeringen på sökfelet och till Lissabon för de tidiga starterna.

Parkeringsplats: incidentrapporter; uppskattningar – först på listan för sprint 32:s retro.

Lägg märke till vad som får sidan att fungera: den första punkten och den näst sista är samma lista sedd med två veckors mellanrum. Sprint 31:s åtgärder föddes längst ned på sprint 30:s sida och bedömdes överst på den här; sprint 32:s kommer att bedömas den 28 november. Den slingan är hela värdet i ett retrospektiv, och det är just den del som de flesta mallar överlåter åt minnet.

Fyra uppsättningar frågor, och när var och en passar

Punkt 3 och 4 i mallen är ett par frågor, och team tröttnar på samma par. Fyra välkända alternativ, som alla fortfarande slutar i punkt 5 och 6:

Oavsett vilken uppsättning du använder gäller två regler: skriva före prata, och resultatet är en eller två åtgärder med ansvariga. En frågeuppsättning som ger en rikare vägg av lappar men inget beslut har gjort mötet mer intressant och mindre användbart.

Var retrospektivet bor i de verktyg du redan använder

Varje större plattform ger retron en tavla eller ett dokument, och var och en stannar vid olika punkt. Bara dokumenterat beteende, från leverantörernas egna sidor, med den månad varje uppgift kontrollerades:

Två saker är lika på varje rad. Retrons tavla är ett dokument bredvid mötet, på det enda språk den skrevs eller hölls på; och om förra retrons åtgärder blev gjorda är en fråga som dokumentet inte besvarar – en person öppnar den förra sidan vid nästa möte och läser upp den för rummet. Där det är bra nog räcker vilken som helst av de fyra och tabellen är hela svaret. Var transkriptet, inspelningen och sammanfattningen av ett Teams- eller Meet-samtal hamnar efteråt, och vem som fortfarande kan öppna dem, kartläggs i var Teams och Meet lagrar ditt transkript, din inspelning och din sammanfattning; vad varje plattforms livetranslation täcker i samtalet och var den slutar finns i guiderna för Teams och Meet (Teams, Meet).

Så överlever åtgärderna till nästa retro

InterMIND är ett kommunikationsutrymme där ett möte lever i en kanal, så retrospektivet har ett givet hem: en egen kanal, där periodens fakta och förra retrons åtgärder läggs upp dagen innan, och där kanalen behåller varje sessions recap, så att sprint 30:s sida ligger ett klick från sprint 31:s. Varje medlem skriver på sitt eget språk och läser de andra på sitt; en sida som utkastats någon annanstans landar i kanalen via e-post – värden ger kanalen en egen adress, och ett meddelande som skickas dit visas som ett vanligt meddelande med avsändaren angiven och bilagorna bevarade.

Under samtalet är tavlan en anteckning som läggs på allas skärm bredvid videorutorna med Share to conference: facilitatorn redigerar den live medan rummet skriver sina punkter, och varje deltagare läser den på sitt eget språk, med originalet ett klick bort. Föregående sessions recap kan delas in i konferensen på samma sätt, så att punkt 1 – förra retrons åtgärder – är den faktiska journalen på allas skärm och inte någons minne av den.

När samtalet tar slut skrivs recapen utifrån själva mötet: en sammanfattning, punkterna markerade som överenskomna, öppna eller omstridda, åtgärdspunkterna med ansvariga, där varje rad behåller sin tidsstämpel. Den kommer med e-post, som ett meddelande i kanalen och som en länk i kalenderhändelsen, och varje inloggad medlem läser den på sitt eget språk – journalen översätts per läsare och skrivs inte en gång på det språk som rummet råkade använda. Vilken medlem som helst kan redigera den, och varje ändring bevarar författare och versionshistorik. Värden kan lägga till en kopia av recapen till valfri adress – en tracker eller en CRM-brevlåda för inkommande – så att de två åtgärderna når systemet där de ska registreras utan att någon behöver vidarebefordra något. Teams och Meet översätter, enligt sin dokumentation ovan, stunden – undertexter i samtalet, en recap på mötets språk; här är det utrymmet som förblir översatt.

I en organisation med statussidor för team påslagna kontrolleras retrons åtgärder också. Varje åtgärd som en recap registrerar går in i organisationens uppgiftskedja, och när nästa recap skrivs bedöms de öppna mot det som sades: en åtgärd som någon rapporterade som klar markeras som klar; en åtgärd som diskuterades men inte blev klar markeras som inte klar, med orsaken med mötets egna ord; en åtgärd som ingen tog upp förblir öppen. Utlåtandena finns på organisationens statussida, vart och ett med den recap det vilar på, och i början av nästa session nämner Mia de öppna punkterna och deras ansvariga – så att punkt 1 i mallen talas om även när ingen öppnade den förra sidan. Statussidor för team är en förhandsfunktion: en organisations administratör slår på dem under Settings → Advanced efter att ha godkänt alfavillkoren (sidan Preview features beskriver var och en).

En gäst – en konsult i sprinten, en kunds ingenjör som bjudits in till en retro – går med via länk, utan konto och utan kostnad, från en telefon eller i webbläsaren, och hör mötet live på sitt eget språk. Ingen journal finns kvar för en gäst efteråt – kontot är gratis, och det är det som gör journalen åtkomlig. Värden tillhandahåller utrymmet och betalar, på en betald plan, bara för medlemmar som varit aktiva under de senaste 28 dagarna; medlemmar som blir tysta behåller sin åtkomst utan kostnad.

• Öppna en komplett recap – en riktig journal som renderas av samma kod som skriver din, åtgärdspunkter inkluderade.
• Testa livedemon – ingen registrering; tala, och hör rummet översatt för varje lyssnare.

Retrospektiv som hantverk överlever varje verktyg: någon måste fortfarande fråga teamet vad som ska ändras och hålla det till två svar. Det som inte behöver överleva är det andra jobbet – att skriva om tavlan efter samtalet, på ett språk, och att öppna nästa retro med frågan om någon gjorde det den förra beslutade.

FAQ

Vad är ett retrospektivmöte?

Ett retrospektiv är ett återkommande möte där ett team tittar på hur det arbetade under en period – en sprint, en release, en månad – och förbinder sig till en eller två förändringar i sitt arbetssätt. Det kontrollerar först förra retrons åtgärder, lägger periodens fakta på tavlan, samlar in vad som gick bra och vad som inte gjorde det skriftligt, grupperar och röstar, och slutar med åtgärder som har en ansvarig och ett kontrolldatum. Det skiljer sig från granskningen, som tittar på vad som byggdes, och från en incidentgranskning, som tittar på ett enskilt fel.

Hur genomför man ett sprintretrospektiv?

Lås tiden efter granskningen och före planeringen, och lägg upp periodens fakta och förra retrons åtgärder i teamets kanal dagen innan. På mötet: kontrollera förra gångens åtgärder (fem minuter), läs fakta, skriv lappar om vad som gick bra och vad som inte gjorde det i tystnad innan någon pratar, läs upp dem, klustra, rösta med två röster var och använd återstoden av tiden till att göra de ett eller två översta klustren till åtgärder med en ansvarig och ett datum. Läs upp åtgärderna, nämn kontrolldatumet – normalt nästa retro – och avsluta med uppskattning. Publicera sidan samma dag där nästa retro kommer att öppna den.

Vilka är retrospektivets 5 steg?

Den allmänt använda femstegsstrukturen är: förbered scenen (syfte, de tidigare åtgärderna, reglerna), samla data (periodens fakta och allas lappar), skapa insikter (gruppera lapparna och hitta mönstret bakom dem), bestäm vad som ska göras (en eller två åtgärder med ansvariga) och avsluta (uppläsning, kontrolldatum, uppskattning). Mallen i den här guiden motsvarar de stegen punkt för punkt: punkt 1–2 förbereder scenen och samlar fakta, 3–5 samlar och grupperar, 6 beslutar, 7 avslutar.

Vad är skillnaden mellan en sprintgranskning och ett sprintretrospektiv?

Granskningen tittar på arbetet – vad som byggdes, om det är vad som avsågs, vad som ändras i backloggen – med intressenter i rummet. Retrospektivet tittar på arbetssättet – vad som bromsade teamet och vad det ska ändra – med enbart teamet. Granskningen lämnar efter sig godkända punkter och ändringar i backloggen; retrospektivet lämnar efter sig en eller två åtgärder om hur teamet arbetar, och förra gångens åtgärder markerade som klara eller inte. Retron ligger efter granskningen så att den utgår från det som faktiskt levererades.

Vad är start, stop, continue?

En uppsättning frågor för retrospektiv med tre kolumner: vad teamet bör börja göra, vad det bör sluta göra och vad det bör fortsätta göra. Den ersätter paret ”gick bra” och ”gick inte bra” i grundmallen och passar team som vill ha åtgärder direkt från lapparna – en ”start”-lapp är redan en halv åtgärd. Gruppering, röstning och gränsen på en eller två åtagna förändringar gäller fortfarande.

Vilka är de 4 frågorna i ett retrospektiv?

Ett klassiskt retrospektiv ställer fyra frågor: vad gjorde vi bra, vad lärde vi oss, vad bör vi göra annorlunda nästa gång och vad förbryllar oss fortfarande. De är de 4 L:en i annan form – liked, learned, lacked, longed for – och fungerar bäst över en längre period, som ett kvartal eller ett projekts slut, där lärande betyder lika mycket som att fixa.

Hur långt bör ett sprintretrospektiv vara?

För en tvåveckorssprint och ett team på fem till tio: 45 till 60 minuter – fem för de tidigare åtgärderna, tre för fakta, sexton för skrivande, femton för uppläsning, klustring och röstning, femton för förändringarna, fem för avslutet. Ett retrospektiv som regelbundet drar över har oftast släppt in granskningen eller en incidentdiskussion i rummet; en retro som är mycket kortare har oftast hoppat över skrivandet eller åtgärderna.

Vad bör en retrospektivmall innehålla?

Sju saker: förra retrons åtgärder med sina lägen; perioden i fakta; vad som gick bra; vad som inte gick bra – båda skriftligt först; gruppering och röster; en eller två förändringar skrivna som åtgärdspunkter med en ansvarig och ett datum; och avslutet – uppläsning, kontrolldatum, uppskattning – med en parkeringsplats för det som fick vänta. De två delar som de flesta mallar hoppar över är den första och den näst sista: kontrollen av gamla åtgärder och ansvarig-och-datum på nya. De är det som binder ihop en retro med nästa.

Källor: 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. Varje tabellcell anger den månad då uppgiften kontrollerades: Microsofts anteckningssida, Zooms agendasida, Googles sidor och Slacks sidor kontrollerades oktober 2026; Microsofts recap-sida och Zooms sida om mötessammanfattning kontrollerades augusti 2026. Femstegsstrukturen och frågeuppsättningarna är vedertagen praxis och innehåller inga påståenden från leverantörer. Leverantörerna ändrar planer, funktioner och språklistor över tid; kontrollera deras sidor för aktuellt läge.