"Hva gikk bra" Sprint Retrospektiv: 27 mønstersvar
Jeg har allerede deltatt i mer enn 200 Sprint Retrospektiver og ofte hørt hva som gikk bra.
Likevel opplever jeg stadig det samme: I mange team er det nesten ingen som kommer på hva som faktisk har gått bra i begynnelsen av retrospektiven. Ikke fordi ingenting var bra. Men fordi vi ofte ser raskere på problemer enn på fremgang.
Det er nettopp derfor dette innlegget er her. Jeg deler mønstersvar som har fungert i ekte sprinter, slik at dere kan synliggjøre gode arbeidsmåter og bevisst gjenta dem i neste sprint.
Jeg skriver dette fra mitt perspektiv som psykolog og Scrum Master.
Hva gikk bra Sprint Retrospektiv: 10 raske mønstersvar
- Positivt: Sprintmålet vårt var tydelig for alle.
- Positivt: Vi eskalerte blokkeringer raskere.
- Positivt: Daily Standups var korte og nyttige.
- Positivt: Code Reviews kom raskere tilbake.
- Positivt: QA ble involvert tidligere.
- Negativt: Vi hadde for mange kontekstbytter og dermed mindre fokustid.
- Negativt: Avstemmingen i teamet var uklar på flere punkter.
- Negativt: User Stories var delvis for unøyaktig formulert.
- Negativt: Action Items fra forrige retro ble ikke fulgt opp konsekvent.
- Negativt: Kommunikasjonen med interessenter var enkelte steder for sen.
Hvorfor spørsmålet “Hva gikk bra” er så viktig
Når jeg modererer retrospektiver, passer jeg bevisst på at vi ikke bare snakker om problemer. Dette spørsmålet er viktig fordi det:
- skaper regelmessig rom for det positive,
- styrker teamfølelsen,
- øker psykologisk trygghet,
- og bevarer gode mønstre for neste sprint.
Hvis du vil gjøre starten på retrospektivene dine mer variert, finner du passende formater i vårt innlegg om Retrospektive Check-ins .
Mønstersvar etter områder
Jeg markerer hvert eksempelsvar bevisst med Positivt eller Negativt, slik at du kan bruke begge deler direkte i teamet.
Mønstersvar: “Hva gikk bra” Sprint Retrospektiv
1) Samarbeid i teamet
- Positivt: Vi støttet hverandre proaktivt ved flaskehalser.
- Positivt: Tilbakemeldinger ble tatt imot åpent og konstruktivt.
- Positivt: Utvikling og QA samarbeidet tettere.
- Negativt: Overleveringer var ikke godt nok forberedt på flere punkter.
- Negativt: Pairing ble knapt brukt, selv om det ville hjulpet ved komplekse temaer.
- Negativt: Teamstemningen var tidvis spent og lite løsningsorientert.
2) Kommunikasjon og møter
- Positivt: Sprintmålet var formulert forståelig for alle.
- Positivt: Daily Standups forble fokuserte og beslutningsorienterte.
- Positivt: Møter endte oftere med klare beslutninger.
- Negativt: Risikoer ble tatt opp for sent.
- Negativt: Kommunikasjon med interessenter var delvis ikke transparent nok.
3) Planlegging og fokus
- Positivt: Backlog Refinement var bedre forberedt.
- Positivt: User Stories var tydeligere beskrevet.
- Positivt: Commitments var satt mer realistisk.
- Negativt: Det kom for mye uplanlagt arbeid inn i sprinten.
- Negativt: Vi hadde for lite fokustid og for mange kontekstbytter.
4) Kvalitet og leveranse
- Positivt: Code Reviews kom raskere tilbake.
- Positivt: QA ble involvert tidligere i gjennomføringen.
- Positivt: Testdekningen av nye funksjoner var bedre.
- Negativt: Kritiske feil ble oppdaget for sent.
- Negativt: For mye arbeid forble halvferdig ved slutten av sprinten.
- Negativt: Definition of Done ble ikke alltid fulgt konsekvent.
5) Kontinuerlig forbedring
- Positivt: Action Items fra forrige retro ble gjennomført.
- Positivt: Vi beholdt aktivt fungerende praksiser.
- Negativt: Forbedringer ble knapt gjort målbare.
- Negativt: Ansvarsområder var ikke alltid klare.
- Negativt: Sprintforløpet virket generelt ustabilt.
Svake vs. sterke svar
Svake svar er som regel for generelle. Sterke svar synliggjør atferd, effekt og neste steg.
| Svakt | Sterkt |
|---|---|
| «Kommunikasjonen var bedre.» | «Vi adresserte blokkeringer direkte i Daily og unngikk dermed to dagers ventetid.» |
| «Kodegjennomgangen gikk bra.» | «Gjennomgangstiden vår sank fra omtrent 24 til 8 timer, noe som gjorde at vi kunne teste tidligere.» |
| «Teamarbeidet var supert.» | «Ved flaskehalser tok to kolleger proaktivt over oppgaver, slik at sprintmålet forble realistisk.» |
Hvis du vil gå dypere inn i konkrete formuleringer for utviklingstilbakemeldinger, hjelper også disse praktiske eksemplene: 20 eksempler på tilbakemeldinger for programvareutvikler-roller .
Kopier-og-lim-mal for retroen
Jeg bruker denne strukturen i hverdagen:
Observasjon + Effekt + Neste steg
Mal 1
«Vi gjorde [konkret atferd]. Dette forbedret [konkret effekt]. I neste sprint beholder vi [konkret tiltak].»
Mal 2
«[Situasjon] gikk spesielt bra. Det hjalp oss med å [resultat]. Neste gang gjentar vi dette gjennom [fremgangsmåte].»
Mal 3
«Sammenlignet med forrige sprint var [aspekt] bedre. Dette var synlig gjennom [signal/måltall]. Derfor standardiserer vi [best praksis].»
Du finner flere metoder for ulike teamsituasjoner i vår oversikt over Retrospektive metoder .
Hvorfor Echometer etter min mening er en sterk start
Når team ønsker å innføre eller forbedre agile retrospektiver, er Echometer etter min mening spesielt nyttig:
- rask oppstart med klar struktur,
- direkte bruk uten store oppsettkostnader,
- mange maler og spørsmål for umiddelbar fasilitering,
- psykologisk fokus for bedre deltakelse,
- oppfølging av tiltak inkludert påminnelser.
Hvis du vil starte med en gang, se på vår Programvare for team-retrospektiver eller Programvare for Team Health Check .
For en dypere forberedelse til fasilitering finner du også vår e-bok med tips til retro-fasilitering .
Ekstern kontekst
For ytterligere perspektiver på retrospektiver synes jeg disse ressursene er nyttige:
FAQ: Hva gikk bra i sprint-retrospektivet?
Hvorfor er retrospektiver viktige?
Retrospektiver hjelper team med å identifisere problemer tidlig, forstå årsaker og i fellesskap beslutte forbedringer. Dette øker åpenhet, teamtilfredshet og kvaliteten på resultatene.
Hvilke feil bør absolutt unngås under den første teamretrospektiven?
Spesielt for team med liten eller ingen erfaring med retrospektiver bør man passe på å unngå følgende feil:
- Feil nr. 1: Retrospektiv som et chat-møte. Ikke alle tilbakemeldinger i et retrospektiv trenger å bli diskutert. Det er kun de temaene som har blitt prioritert sammen, som fortjener ekstra oppmerksomhet. Alle diskusjoner om detaljer før avstemningen bør derfor avlyses og utsettes til etter avstemningen.
- Feil nr. 2: Retrospektiv som et spill om skyld. Retrospektivet er ikke til for å skyve ansvaret over på andre eller klandre andre for negative hendelser eller utviklinger. Det er alle teammedlemmenes oppgave å forbedre status quo!
- Feil nr. 3: Retrospektiv som en klageboks. Retrospektiv handler ikke bare om å konstatere hva som ikke fungerer bra. Mesteparten av energien bør brukes på å tenke fremover og definere forpliktende tiltak.
For den første retrospektiven er det lurt å bruke et dedikert retro-verktøy som støtte. Echometer er veldig bra for uerfarne team med sin intuitive og guidede modus. Her kan du prøve en retrospektive i Echometer: https://my.echometerapp.com/retro-setup
Hvordan måler man suksessen til en retrospektive?
Suksessen til retrospektiver viser seg ved at avtalte tiltak iverksettes og målbare forbedringer oppstår. Team bruker i tillegg til produktivitetsindikatorer (som man bør være forsiktig med) f.eks. sporing av Action Items, trender på feedback-skalaer i Team Health-Check- / Pulse-Check-undersøkelser.
Bidrar det retrospektive programvareverktøyet Echometer til å øke den psykologiske tryggheten i team?
Ja, Echometer er sannsynligvis det retrospektive verktøyet med sterkest psykologisk fokus, ettersom det opprinnelig er en spin-off fra det psykologiske fakultetet ved Universitetet i Münster (Tyskland). Echometer bidrar til å styrke den psykologiske tryggheten i team (med programvareutvikling og hybride produktteam som primær målgruppe) ved hjelp av ulike icebreakers og retrospektive maler.
På den ene siden bidrar for eksempel de morsomme bli-kjent-spørsmålene som en del av retrosjekken til å styrke den psykologiske tryggheten i teamene. På den andre siden finnes det for eksempel egne maler for måling av psykologisk trygghet i team.
Hvordan sikrer Echometer at retrospektive tiltak blir implementert - er det påminnelser?
Ja, det retrospektive programvareverktøyet Echometer lar deg også lagre påminnelser om tiltak. Disse sendes via e-post til den som er ansvarlig for tiltaket. Dette sikrer at gjennomføringen av tiltaket ikke blir glemt.
Konklusjon
Spørsmålet «Hva gikk bra?» er ikke bare hyggelig småprat i starten av et retrospektiv. Det er den raskeste måten å synliggjøre velfungerende teammønstre og ta dem med inn i neste sprint.
Når du jobber med klare Mønstersvar «Hva gikk bra» Sprint Retrospektiv og kombinerer det positive perspektivet med konkrete tiltak, øker som regel ikke bare kvaliteten på retrospektivet, men også fokus, teamfølelse og forpliktelse i hverdagen.
