Sprintretrospektiv — är ett regelbundet möte för utvecklingsteamet som hålls i slutet av varje sprint för att analysera den gångna perioden och söka förbättringar. Till skillnad från daily stand-ups och sprint review fokuserar retrospektivet på processer och interaktion, inte på produkten. Enligt Scrum Guide, 2020 är retrospektivet en av de fem obligatoriska Scrum-händelserna och fungerar som en nyckelmekanism för kontinuerlig teamförbättring.
Huvudpunkter
Sprintretrospektiv — är ett strukturerat möte för Scrum-teamet som äger rum efter sprintens slut och före planeringen av nästa. Deltagarna diskuterar den gångna sprinten, delar observationer och bestämmer tillsammans vilka förändringar som ska införas i arbetet.
Termen retrospektiv kommer från praktiker för kontinuerlig förbättring som beskrivs i DevOps-kulturen och Lean-metodologin. I Scrum blev retrospektivet en obligatorisk händelse med lanseringen av Scrum Guide 2010. År 2020, i uppdateringen av Scrum Guide, flyttades fokus från ”inspektion och anpassning” till ”fokus på kvalitet och effektivitet”, vilket stärkte retrospektivens roll.
Sprint Review fokuserar på produkten och feedback från intressenter, medan retrospektivet fokuserar på teamets processer. Daily Scrum — är daglig synkronisering, retrospektivet — analys över hela sprinten. Retrospektivet är den enda ceremonin där teamet uteslutande talar om sig självt, utan påtryckningar från kunden eller product ownern.
Sprintretrospektivet har flera viktiga mål, som alla är viktiga för en sund utveckling av teamet och utvecklingsprocessen.
Reflektion gör att teamet kan förstå den gångna sprinten: vad som lyckades, vad som gick fel och vilka lärdomar som kan dras. Denna process förhindrar upprepning av samma misstag, skapar en kultur av öppenhet och lär utvecklare att ta ansvar för processer, inte bara för kod.
Varje retrospektiv bör generera konkreta åtgärdspunkter — uppgifter för nästa sprint. Till exempel: ”lägg till code review för alla pull requests” eller ”förkorta daily stand-up till 10 minuter”. Åtgärdspunkterna registreras i backloggen och följs upp vid nästa retro. Om åtgärdspunkterna inte utförs förlorar retrospektivet sin mening.
Regelbundna retrospektiv hjälper till att identifiera problem innan de leder till utbrändhet. Övertid, konflikter i teamet, otydliga krav — allt detta tas upp på retron och löses innan det når kritisk massa.
Det finns över 50 retrospektivformat, var och en lämplig för olika situationer och teamsammansättningar. Valet av format beror på teamets mognad, aktuella problem och tillgänglig tid.
| Format | Beskrivning | När ska det användas |
|---|---|---|
| Start-Stop-Continue | Teamet delar in idéer i tre kolumner: börja, sluta, fortsätt | Första retron eller efter en kris |
| Sailboat | Visuell metafor: vinden (vad som hjälper), ankaret (vad som saktar ner), stenarna (risker) | Teamet har tröttnat på mallar |
| 4L (Liked-Learned-Lacked-Longed For) | Fyra kategorier: gillade, lärde sig, saknade, önskade | Djupgående analys av sprinten |
| Mad-Sad-Glad | Emotionellt format: gör arg, ledsen, glad | Det finns emotionell spänning |
Start-Stop-Continue — det enklaste och mest populära formatet. Teamet skriver idéer på lappar och fördelar dem i tre kolumner. Start — nya rutiner, Stop — skadliga vanor, Continue — vad som fungerar. Formatet är utmärkt för nya team och snabba 30-minutersretrospektiv.
Sailboat (eller ”Segelbåt”) använder metaforen av ett skepp: vinden trycker framåt, ankaret saktar ner, stenarna — framtida risker. 4L — ett djupare format där teamet analyserar varje aspekt genom fyra linser. Båda formaten kräver mer tid (60-90 minuter) men ger en mer komplett bild av teamets tillstånd.
För veckovisa retrospektiv är lätta format lämpliga: Start-Stop-Continue eller Mad-Sad-Glad. För sprintar på 2-4 veckor är det värt att använda Sailboat eller 4L. Om det finns en konflikt i teamet — börja hellre med Mad-Sad-Glad för att släppa ut känslor och gå sedan över till konstruktiv diskussion.
Att genomföra ett retrospektiv kräver struktur och facilitering. Scrum Master eller en utsedd facilitator leder mötet steg för steg så att varje deltagare blir hörd.
24 timmar före retron samlar facilitatorn in data: sprintmetriker (velocity, antal buggar, slutförda uppgifter), teamstämning via anonym enkät. Retro-tavlan förbereds i förväg — fysisk (lappar, pennor) eller digital (Miro, Mural, Retrium).
I denna fas skriver varje deltagare sina observationer på lappar (vanligtvis 5-10 minuter under tystnad). Kategorierna beror på valt format. Viktig regel: kritisera inte andras lappar under insamlingsfasen — först registreras alla idéer, sedan diskuteras de.
Efter insamlingen grupperar teamet lapparna efter ämne och röstar på de viktigaste. Varje deltagare får 3-5 röster (punkter på lapparna). Ämnena med flest röster går till diskussion. Denna mekanism förhindrar att en röst dominerar över de andra.
Den sista fasen — formulering av åtgärdspunkter. Varje åtgärdspunkt bör vara SMART: specifik, mätbar, uppnåelig, relevant och tidsbunden. Den ansvariga personen utses öppet, deadline fastställs. Åtgärdspunkterna läggs till i backloggen och kontrolleras vid nästa retrospektiv.
Även erfarna team gör misstag i retrospektiv som förvandlar en användbar praxis till en tom formalitet. Kännedom om dessa misstag hjälper till att undvika dem.
Det vanligaste misstaget — diskussion utan resultat. Teamet pratade, identifierade problem, men antecknade ingen åtgärdspunkt. Ett sådant retrospektiv leder inte till förändringar, och vid nästa möte diskuteras samma problem. Lösning: ägna alltid de sista 10 minuterna av retron åt åtgärdsplanen.
När retrospektivet förvandlas till en klagostund utan konstruktiva förslag, sjunker teamets moral. Facilitatorn bör styra diskussionen från problem till lösningar. Teknik: efter varje problem, ställ frågan ”Vad kan vi göra åt detta?”.
Om en utvecklare pratar 80% av tiden, stänger de andra av och slutar dela idéer. Lösning: använd tyst idéinsamling (alla skriver sina egna), turas om att prata, timer för anföranden. Anonyma enkäter före retron hjälper också att samla in åsikter från tysta deltagare.
Att hoppa över retro på grund av fullt schema eller ”inte tid” — en farlig trend. Om teamet hoppar över en retro blir det lättare att hoppa över nästa. Med tiden ackumuleras problemen och sprintarna blir mindre effektiva. Retrospektivet är en del av sprinten precis som utveckling och testning.
Vanliga frågor
Retrospektiv hålls efter varje sprint, oavsett dess längd. För sprintar på 1-2 veckor räcker 30-60 minuter. Om sprinten är kort (en vecka) kan det lätta formatet Start-Stop-Continue användas. Att hoppa över retrospektiv rekommenderas inte — det är den viktigaste mekanismen för kontinuerlig teamförbättring.
I retrospektivet deltar hela Scrum-teamet: utvecklare, Scrum Master och Product Owner. Product Owner kan delta som medlem, men hans åsikt bör inte dominera. Om externa specialister (designers, analytiker) deltog i sprinten — bjud in dem också. Huvudregel: alla som arbetade i sprinten har rösträtt på retron.
Ovilja att delta — ett symptom på djupare problem: misstro mot ledningen, rädsla för bestraffning eller utbrändhet. Börja med anonyma enkäter för att förstå orsaken. Ändra formatet till ett mer lekfullt (Sailboat, Mad-Sad-Glad). Minska tiden till 15-20 minuter. Visa värdet: börja med små förändringar som teamet kommer att se och uppskatta.
Ja, retrospektiv på distans genomförs effektivt via digitala whiteboards (Miro, Mural, Retrium, Google Jamboard). Använd timers för synkrona faser, Video-on är obligatoriskt för alla deltagare. Asynkrona retrospektiv fungerar också: teamet fyller i tavlan under dagen och diskuterar sedan resultaten i 30 minuter. Retrospektiv på distans kräver tydligare facilitering.
Retrons effektivitet ökas genom: rotation av facilitatorn (för att inte vänja sig vid en stil), byte av format var 3-4 sprint, fokus på åtgärdspunkter, uppföljning av slutförda uppgifter vid nästa retro. Använd metriker: velocity, antal buggar, teamstämning. Huvudindikatorn för effektivitet — de förändringar som teamet faktiskt implementerade efter retron.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också