Ladda ner vår mall för retrospektiv
Skriv ut den till väggen eller redigera den i verktyget du redan använder. Gratis, utan e-post och utan registrering. Filerna är på engelska.
En agil retrospektiv är ett kort, regelbundet möte där ett team ser tillbaka på en arbetsperiod, vanligtvis en sprint, och kommer överens om vad de ska ändra i hur de arbetar. Ett planeringsmöte handlar om vad teamet ska bygga; en retrospektiv handlar om hur det bygger. Resultatet är inte en lista med klagomål utan en eller två konkreta förändringar som teamet kommer att prova före nästa retrospektiv.
Retrospektiver kommer direkt från Agila Manifestet från 2001, vars sista princip ber team att regelbundet reflektera över hur de kan bli mer effektiva och sedan anpassa sitt beteende. I Scrum är Sprintretrospektiven händelsen som avslutar varje sprint.
Denna guide täcker de fem stegen i en bra retrospektiv, hur de vanligaste formaten jämförs, och ett praktiskt exempel som tar ett team från post-it-lappar till en enda konkret förändring med en ägare.
Den korta versionen
En retrospektiv har gjort sitt jobb när teamet lämnar mötet med en specifik förändring, en ägare och ett sätt att avgöra om det fungerade. Allt annat i mötet syftar till att hitta den förändringen.
Huvuddirektivet
De flesta retrospektiver inleds med att återupprepa Retrospektivens Huvuddirektiv, skrivet av Norm Kerth i Project Retrospectives (2001). Kort sagt: oavsett vad vi upptäcker, antar vi att alla gjorde sitt bästa med det de visste, sina färdigheter, tillgängliga resurser och situationen vid tillfället.
Det är inte där för att vara artigt. Ett team som förväntar sig att få skulden kommer att ge säker, generisk feedback och dölja den verkliga orsaken. Att ta bort skulden från bordet är det som gör att människor kan säga "Jag visste inte att specifikationen hade ändrats" högt, och den meningen är oftast där den användbara delen av mötet börjar.
De fem stegen i en retrospektiv
Esther Derby och Diana Larsens bok Agile Retrospectives beskriver fem steg som nästan varje bra retrospektiv följer, oavsett vilket format den använder:
| Steg | Syfte | Typisk tid i en 45-minuters retro |
|---|---|---|
| 1. Sätt scenen | Återupprepa målet och Huvuddirektivet; få alla att prata tidigt | 5 minuter |
| 2. Samla data | Samla in vad som hände: fakta, händelser och hur människor kände | 10 minuter |
| 3. Generera insikter | Gruppera data, välj det största temat och hitta dess grundorsak | 15 minuter |
| 4. Bestäm vad ni ska göra | Välj en eller två förändringar, var och en med en ägare | 10 minuter |
| 5. Avsluta | Bekräfta åtagandena och kontrollera hur mötet gick | 5 minuter |
Det steg team oftast hoppar över är det tredje. Att gå direkt från "här är våra post-it-lappar" till "här är våra åtgärder" leder till åtgärder som behandlar symptom.
Vanliga retrospektivformat
Formatet är den uppsättning frågor du använder i steg 2. Att rotera format håller en regelbunden retrospektiv från att bli tråkig.
| Format | Frågor | Bäst för |
|---|---|---|
| Starta, Stoppa, Fortsätt | Vad ska vi börja, sluta och fortsätta göra? | Nya team; snabba retros |
| Starfish | Fortsätt göra, mer av, mindre av, sluta göra, börja göra | Team som vill ha nyanser utöver "bra" och "dåligt" |
| Arg, Ledsen, Glad | Vad frustrerade, besvikna eller gladde dig? | Sprintar som var känslomässigt svåra |
| 4L | Gillade, lärde mig, saknade, längtade efter | Slutet av ett projekt eller ett kvartal |
| Segelbåt | Vind (vad som hjälpte), ankare (vad som saktade ner oss), stenar (risker framåt) | Team som går in i en riskfylld period |
| Tidslinje | Rita upp sprintens nyckelhändelser, markera sedan toppar och dalar | Efter incident eller efter release-granskningar |
Starfish, som vanligtvis tillskrivs Patrick Kua, är det format vår gratis retrospektivmall använder. Dess fem kategorier ger utrymme för "detta fungerar men vi överdriver det", vilket en enkel bra/dålig uppdelning missar.
Ett praktiskt retrospektivexempel
Här är en 45-minuters retrospektiv för ett fiktivt sju-personers produktteam. Deras tvåveckorssprint slutade med att en kundexportfunktion levererades tre dagar för sent.
Steg 1: Sätt scenen (5 minuter)
Facilitatorn återupprepar Huvuddirektivet och anger målet: "Vi levererade exporten tre dagar för sent. Låt oss ta reda på varför och komma överens om en förändring för nästa sprint." Alla ger en enords-sammanfattning av sprinten. Två personer säger "stressigt."
Steg 2: Samla data (10 minuter)
Teamet bygger en snabb tidslinje över sprinten och skriver sedan Starfish-anteckningar i tystnad i fem minuter så att den högljuddaste rösten inte sätter agendan.
| Fortsätt göra | Mer av | Mindre av | Sluta göra | Börja göra |
|---|---|---|---|---|
| Dagliga standups under 15 minuter | Parprogrammering på kluriga stories | Ad-hoc designgranskningar i chatt | Ändra acceptanskriterier mitt i sprinten | Visa design för kunden före sprinten |
| Skriva tester före sammanslagning | Demostrationer för kunden | Statusmöten som kunde vara ett meddelande | Börja stories utan en slutgiltig mockup |
Steg 3: Generera insikter (15 minuter)
Teamet klustrar anteckningarna och röstar. Det största klustret handlar, överlägset, om krav som ändrades efter att sprinten startade. Teamet kör 5 Varför på det:
- Varför levererades exporten sent? Testning visade att den inte matchade vad kunden förväntade sig.
- Varför? Acceptanskriterierna ändrades på dag sex av sprinten.
- Varför? Kundens driftansvarige såg designen för första gången på dag fem.
- Varför? Designer granskas internt men visas inte för kunden innan en story går in i sprinten.
- Varför? Ingen äger kundens godkännande. Produkt antog att kontohantering skötte det, och kontohantering antog att produkt gjorde det.
Grundorsaken är inte "kommunikation". Det är ett steg i processen utan ägare.
Steg 4: Bestäm vad ni ska göra (10 minuter)
Någon föreslår "kommunicera bättre med kunden." Facilitatorn trycker tillbaka: det är en önskan, inte en förändring. Teamet kommer istället överens om ett experiment:
- Förändring: under de kommande två sprintarna behöver varje story med en kundvänd förändring en kundgranskad mockup innan den går in i sprinten.
- Ägare: produktchefen.
- Hur vi vet: räkna antalet stories vars acceptanskriterier ändras efter att sprinten startar. Förra sprinten var det tre.
De andra anteckningarna hamnar på en lista för att återbesökas. Teamet åtar sig en förändring, inte sju.
Steg 5: Avsluta (5 minuter)
Facilitatorn läser upp experimentet och ägaren, och varje person betygsätter retrospektiven från ett till fem. Nästa retrospektiv kommer att inledas med att kontrollera räkningen.
Vad som får en retrospektiv att misslyckas
- Ingen åtgärd, eller för många. En lista med tio förbättringar är en lista som ingen äger. Välj en eller två.
- Åtgärder som är önskningar. "Kommunicera bättre" kan inte göras på måndag. "Kunden godkänner mockups före sprinten" kan.
- Aldrig kontrollera förra gångens åtgärd. Om nästa retrospektiv inte inleds med att granska den senaste förändringen, lär sig teamet att åtaganden är valfria.
- Skuld. När en person pekas ut börjar alla andra redigera vad de säger.
- Samma format varje gång. Rotera frågorna så att teamet inte ger samma svar på autopilot.
Att hoppa över retrospektiver helt har sin egen kostnad, vilket vi täcker i kostnaden för processkuld.
Retrospektiv vs. sprintgranskning vs. postmortem
Dessa tre förväxlas eftersom de alla ser tillbaka:
- Sprintgranskning: teamet visar vad det byggde för intressenter och får feedback på produkten.
- Retrospektiv: teamet tittar på hur det arbetade och ändrar sin process. Intressenter är oftast inte i rummet.
- Postmortem: en engångsgranskning av en specifik incident eller ett misslyckande. Den använder ofta samma steg, med en tidslinje i centrum.
Gratis retrospektivmall
Den gratis retrospektivmallen finns som PDF, Word-dokument, Excel-arbetsbok och PowerPoint-presentation. Den använder Starfish-formatet, med frågor för var och en av de fem kategorierna och en åtgärdsspårare för ägare och datum.
Fortsätt med retrospektiver
- Så här håller du en projektretrospektiv: facilitatorns tankesätt och hur man hanterar ett upphettat rum.
- Så här håller du en sprintretrospektiv i Microsoft Teams: en 45-minuters fjärr-playbook.
- Kostnaden för processkuld: varför att hoppa över retrospektiver saktar ner team.
Vanliga frågor
Hur ofta ska ett team hålla en retrospektiv?
I slutet av varje sprint, eller varannan till var fjärde vecka för team som inte arbetar i sprintar. Att hålla en efter en större release eller incident är också vanligt.
Hur lång tid ska en retrospektiv ta?
Cirka 45 minuter för en tvåveckorssprint. Scrum Guide begränsar Sprintretrospektiven till tre timmar för en enmånadssprint och noterar att den vanligtvis är kortare för kortare sprintar.
Vem ska delta i en retrospektiv?
De personer som utförde arbetet: leveransteamet, inklusive produktägaren och Scrum Master i Scrum. Chefer och intressenter håller sig vanligtvis utanför, så att människor kan tala öppet.
Vem ska facilitera en retrospektiv?
Ofta Scrum Master eller en roterande teammedlem. Rotation hjälper, och för en spänd retrospektiv kan en extern facilitator hålla rummet fokuserat på processen snarare än på personer.
Vad är resultatet av en retrospektiv?
En eller två specifika processförändringar, var och en med en ägare och ett sätt att avgöra vid nästa retrospektiv om det fungerade.
Redo att omsätta det här i praktiken? Kör det med ditt team med hjälp av vår gratis mall för retrospektiv.
