"Hvad gik godt" Sprint Retrospektiv: 27 mønstersvar
Jeg har allerede deltaget i mere end 200 Sprint Retrospektiver og har ofte hørt, hvad der gik godt.
Alligevel oplever jeg det samme igen og igen: I mange teams er der i starten af retrospektivet næsten ingen, der kan komme i tanke om, hvad der egentlig gik godt. Ikke fordi intet var godt. Men fordi vi ofte ser hurtigere på problemer end på fremskridt.
Det er præcis det, dette indlæg er til for. Her deler jeg mønstersvar, der har fungeret i virkelige sprints, så I kan gøre gode arbejdsmetoder mere synlige og bevidst gentage dem i næste sprint.
Jeg skriver dette ud fra mit perspektiv som psykolog og Scrum Master.
Hvad gik godt Sprint Retrospektiv: 10 hurtige mønstersvar
- Positivt: Vores sprintmål var klart for alle.
- Positivt: Vi eskalerede blokeringer hurtigere.
- Positivt: Daily Standups var korte og hjælpsomme.
- Positivt: Code reviews kom hurtigere retur.
- Positivt: QA blev inddraget tidligere.
- Negativt: Vi havde for mange kontekstskift og dermed mindre fokustid.
- Negativt: Afstemningen i teamet var uklar flere steder.
- Negativt: User Stories var til dels formuleret for upræcist.
- Negativt: Action items fra sidste retro blev ikke implementeret konsekvent.
- Negativt: Kommunikationen med interessenter var visse steder for sen.
Hvorfor spørgsmålet “Hvad gik godt” er så vigtigt
Når jeg faciliterer retrospektiver, sørger jeg bevidst for, at vi ikke kun taler om problemer. Dette spørgsmål er vigtigt, fordi det:
- regelmæssigt skaber plads til det positive,
- styrker teamfølelsen,
- øger den psykologiske tryghed,
- og konserverer gode mønstre til næste sprint.
Hvis du vil gøre din start på retrospektiver mere varieret, kan du finde passende formater i vores indlæg om Retrospektive check-ins .
Mønstersvar efter områder
Jeg markerer bevidst hvert eksempelsvar med Positivt eller Negativt, så du kan bruge begge dele direkte i teamet.
Mønstersvar: “Hvad gik godt” Sprint Retrospektiv
1) Samarbejde i teamet
- Positivt: Vi støttede hinanden proaktivt ved flaskehalse.
- Positivt: Feedback blev modtaget åbent og konstruktivt.
- Positivt: Udvikling og QA arbejdede tættere sammen.
- Negativt: Overleveringer var flere steder ikke forberedt ordentligt.
- Negativt: Pairing blev næsten ikke brugt, selvom det ville have hjulpet ved komplekse emner.
- Negativt: Teamstemningen var til tider anspændt og ikke særlig løsningsorienteret.
2) Kommunikation og møder
- Positivt: Sprintmålet var formuleret forståeligt for alle.
- Positivt: Daily Standups forblev fokuserede og beslutningsorienterede.
- Positivt: Møder sluttede oftere med klare beslutninger.
- Negativt: Risici blev italesat for sent.
- Negativt: Interessentkommunikation var til dels ikke transparent nok.
3) Planlægning og fokus
- Positivt: Backlog Refinement var bedre forberedt.
- Positivt: User Stories var beskrevet tydeligere.
- Positivt: Commitments var sat mere realistisk.
- Negativt: Der kom for meget uplanlagt arbejde ind i sprintet.
- Negativt: Vi havde for lidt fokustid og for mange kontekstskift.
4) Kvalitet og levering
- Positivt: Code reviews kom hurtigere retur.
- Positivt: QA blev inddraget tidligere i implementeringen.
- Positivt: Testdækningen af nye funktioner var bedre.
- Negativt: Kritiske fejl blev først opdaget sent.
- Negativt: For meget arbejde forblev halvfærdigt ved sprintets afslutning.
- Negativt: Definition of Done blev ikke altid overholdt konsekvent.
5) Kontinuerlig forbedring
- Positivt: Action items fra sidste retro blev implementeret.
- Positivt: Vi bibeholdt aktivt velfungerende praksisser.
- Negativt: Forbedringer blev næsten ikke gjort målbare.
- Negativt: Ansvarsområder var ikke altid klare.
- Negativt: Sprint-forløbet virkede generelt ustabilt.
Svage vs. stærke svar
Svage svar er ofte for generelle. Stærke svar synliggør adfærd, effekt og det næste skridt.
| Svag | Stærk |
|---|---|
| „Kommunikationen var bedre.“ | „Vi adresserede blokeringer direkte i vores Daily og undgik dermed to dages ventetid.“ |
| „Code Review gik godt.“ | „Vores review-tid faldt fra ca. 24 til 8 timer, hvilket gjorde det muligt for os at teste tidligere.“ |
| „Teamworket var super.“ | „Ved flaskehalse overtog to kolleger proaktivt opgaver, hvilket betød, at sprint-målet forblev realistisk.“ |
Hvis du vil gå dybere ind i konkrete formuleringer til udviklingsfeedback, kan disse praktiske eksempler også hjælpe: 20 feedback-eksempler til softwareudvikler-roller .
Copy-paste skabelon til din retro
Jeg bruger denne struktur i hverdagen:
Observation + effekt + næste skridt
Skabelon 1
„Vi gjorde [konkret adfærd]. Som følge heraf blev [konkret effekt] forbedret. I næste sprint bibeholder vi [konkret tiltag].“
Skabelon 2
„[Situation] gik særligt godt. Det hjalp os med at [resultat]. Næste gang gentager vi det ved at [fremgangsmåde].“
Skabelon 3
„I forhold til sidste sprint var [aspekt] bedre. Det kunne ses på [signal/metrik]. Derfor standardiserer vi [best practice].“
Du finder flere metoder til forskellige teamsituationer i vores oversigt over Retrospektive metoder .
Hvorfor Echometer efter min mening er en stærk start
Når teams ønsker at indføre eller forbedre agile retrospektiver, er Echometer efter min mening særligt hjælpsom:
- hurtig start med en klar struktur,
- direkte brug uden det store setup-arbejde,
- mange skabeloner og spørgsmål til øjeblikkelig facilitering,
- psykologisk fokus for bedre deltagelse,
- tracking af tiltag inklusiv påmindelser.
Hvis du vil starte med det samme, så tag et kig på vores Team Retrospektive Software eller Team Health Check Software .
For en mere dybdegående forberedelse til facilitering finder du desuden vores e-bog med tips til retro-facilitering .
Ekstern kontekst
For yderligere perspektiver på retrospektiver finder jeg disse ressourcer hjælpsomme:
FAQ: Hvad gik godt i sprint-retrospektivet?
Hvorfor er retrospektiver vigtige?
Retrospektiver hjælper teams med at identificere problemer tidligt, forstå årsager og i fællesskab beslutte forbedringer. Dette øger gennemsigtighed, teamtilfredshed og resultatkvalitet.
Hvilke fejl bør absolut undgås under det første team-retrospektiv?
Især for teams med ringe eller ingen erfaring med retrospektiver bør man sørge for at undgå følgende fejl:
- Fejl nr. 1: Retrospektiv som et chatmøde. Ikke al feedback i et retrospektiv behøver at blive diskuteret. Kun de emner, der er blevet prioriteret sammen, fortjener ekstra opmærksomhed. Alle diskussioner om detaljer før afstemningen bør derfor aflyses og udskydes til efter afstemningen.
- Fejl nr. 2: Retrospektiv som et spil om skyld. Retrospektivet er ikke til for at flytte ansvaret eller give andre skylden for negative begivenheder eller udviklinger. At forbedre status quo ligger i hænderne på alle teammedlemmer!
- Fejl nr. 3: Retrospektiv som en brokkekasse. Retrospektiver handler ikke kun om at notere, hvad der ikke fungerer godt. Det meste af energien bør fokuseres på at tænke fremad og definere bindende tiltag.
Til den første retrospektive er det en god idé at bruge et dedikeret retro-værktøj som støtte. Echometer er med sin intuitive og guidede tilstand meget velegnet til uerfarne teams. Her kan du prøve en retrospektive i Echometer: https://my.echometerapp.com/retro-setup
Hvordan måler man succesen af en retrospektive?
Succesen af retrospektiver viser sig ved, at aftalte tiltag implementeres, og der opstår målbare forbedringer. Teams bruger til dette, ud over produktivitetsnøgletal (som skal tages med forbehold), f.eks. opfølgning af Action Items, tendenser på feedback-skalaer i Team Health-Check- / Pulse-Check-undersøgelser.
Hjælper det retrospektive softwareværktøj Echometer med at øge den psykologiske sikkerhed i teams?
Ja, Echometer er nok det retrospektive værktøj med det stærkeste psykologiske fokus, da det oprindeligt er et spin-off fra det psykologiske fakultet ved universitetet i Münster (Tyskland). Konkret hjælper Echometer med at styrke den psykologiske sikkerhed i teams (med den primære målgruppe af softwareudviklings- og hybridproduktteams) gennem forskellige icebreakers og retrospektive skabeloner.
På den ene side hjælper f.eks. de sjove lær-dig-at-kende-spørgsmål som en del af retro-check-in med at styrke den psykologiske sikkerhed i teams. På den anden side er der f.eks. dedikerede skabeloner til måling af psykologisk sikkerhed i teams.
Hvordan sikrer Echometer, at retrospektive tiltag implementeres - er der påmindelser?
Ja, det retrospektive softwareværktøj Echometer giver dig også mulighed for at gemme påmindelser om tiltag. Disse sendes via e-mail individuelt til den person, der er ansvarlig for foranstaltningen. Det sikrer, at implementeringen af foranstaltningen ikke bliver glemt.
Konklusion
Spørgsmålet “Hvad gik godt?” er ikke bare venlig smalltalk i starten af et retrospektiv. Det er den hurtigste måde at synliggøre velfungerende team-mønstre og tage dem med ind i næste sprint.
Når du arbejder med klare Svarskabeloner til „Hvad gik godt“ i sprint-retrospektivet og kombinerer det positive perspektiv med konkrete tiltag, stiger normalt ikke kun kvaliteten af retrospektivet, men også fokus, teamfølelse og forpligtelse i hverdagen.
