Sprint Retrospective
Silent writing first, discussion second, actions last. The structure that keeps retros honest.
Free, no sign-up. Editable, copy as Markdown, plain text, or calendar.
Pick a duration
Before the meeting
- Pick a retro format (Start/Stop/Continue, 4Ls, Sailboat, or similar)
- Send prompts to the team the day before so they can think informally
- Review the actions from the last retro and note which landed
After the meeting
- Post actions in the team channel with owners and deadlines
- Add actions to the team's working tracker so they don't get forgotten
- Review action status at the start of the next retro
More agenda templates
About the sprint retro agenda
A sprint retrospective is a recurring meeting where the team reflects on the last sprint and commits to what to change. The agenda below is deliberately simple because the format matters less than the consistency. Teams that run a tight 45 minutes every sprint outperform teams that run a sprawling 90-minute retro once a quarter, every time.
What makes a retro work?
Psychological safety, structured silence, and a hard commit to one to three actions. The silent-writing round is the most underrated technique in retros. It sidesteps the loudest-voice problem entirely and lets people who think before they talk get a fair shot at the agenda.
How long should a sprint retro be?
For a two-week sprint, 45 minutes is a good default. For a one-week sprint, 25 minutes. Longer is rarely better. If your retros need more time, that usually means you are using the meeting to do work that should have happened earlier, like surfacing blockers in real time.
Who should facilitate?
Rotate. Every facilitator brings a different style and the team gets to learn from all of them. Engineering managers should not default to facilitating their own team's retros because it makes it harder for the team to bring up management-related issues.
How do you stop retros going stale?
Change the prompts every few sprints. Even switching between Start/Stop/Continue and 4Ls is enough to keep answers fresh. When the team starts answering on autopilot, the format has worn out. Our retro prompt generator has hundreds of prompts across ten frameworks for exactly this.
Frequently asked
- How long should a sprint retrospective be?
- Forty-five minutes for a two-week sprint. Twenty-five minutes for a one-week sprint. Longer is rarely better. If your retro routinely runs over, the issue is usually that you are surfacing blockers in the retro that should have come up in standups or async.
- What is the best sprint retrospective format?
- The best format is one the team hasn't used in the last three sprints. Even solid formats like Start/Stop/Continue go stale. Rotate between Start/Stop/Continue, 4Ls, Sailboat, Mad/Sad/Glad, and KALM so answers don't become scripted.
- How do you run a good retro with a remote team?
- Use a shared virtual whiteboard (Miro, FigJam, or equivalent) for silent writing and clustering. Give people five minutes in silence, not three. Remote retros need more structured silence than in-person ones because you lose the nonverbal cues that keep a discussion alive.
- Who should facilitate the sprint retrospective?
- Rotate facilitators. Every facilitator brings a different style and the team learns from all of them. Engineering managers should not default to facilitating their own team's retros; it makes it harder for the team to bring up management-related issues.
When to use this template
At the end of every sprint. Two-week sprints get a 45-minute retro, one-week sprints get a 25-minute one. Quarterly retros are useful for larger trends but do not replace the sprint-level one.