Sprint retrospective template
A retro doc your agent fills in under a minute — then you share one link the team annotates inline. Action items anchored to the exact line, not scattered across Slack and meeting chat.
Most retros fail at the same point: the doc dies in a shared drive, action items live in the meeting chat until they don't, and sprint three has the same conversation as sprint one. Draft the doc with your agent, share a Drafty link, and let the team react inline — so every "we need to fix this" lands anchored to the exact line it's about.
Generate it with your agent
Paste this into Claude, Cursor, or any agent:
See it on a real one
What goes in a sprint retrospective
Four sections. More than four and you're running a post-mortem, not a retro.
- What went well — specific, not generic. "We shipped the feature" is fine; "CI finally stopped flaking after we pinned the runner version" is better. Specifics travel to the next sprint; vague praise doesn't.
- What didn't — the blockers, the dropped balls, the process that slowed everyone down. Name the system, not the person. "We had no clear owner for the API decision" is useful; "Alex was slow" isn't.
- Action items — the most misused section in every retro template. Three max. Each one needs an owner (one name, not "the team") and a done-condition ("update the deployment runbook" not "improve deployments"). If you can't define done, the item won't get done.
- Shoutouts — optional, but worth it. One line each. Teams that skip this section consistently report lower retro engagement over time.
The section most teams get wrong
Action items. The Scrum Guide says each retrospective should produce at least one improvement to be enacted in the next sprint. In practice, teams routinely close retros with five to eight action items, assign them to "the team," and open the next retro by skipping past the previous one.
The fix isn't a better template — it's a constraint. Cap at three. Name one person per item. Write the done-condition before you leave the meeting. Share the retro doc as a link so those three items are one click away from any standup or sprint planning session.
Which format to pick
Start / Stop / Continue — the right default for most teams. What to start doing, what to stop, what to keep. Fast to fill, easy to action.
Mad / Sad / Glad — useful when team health is the real issue and you need the emotional layer surfaced before you can talk process. Not a substitute for Start/Stop/Continue; more of a precondition.
Sailboat / 4Ls / Starfish — worth rotating in every few sprints if engagement drops. The same format every two weeks will produce the same low-energy responses after a month.
The format matters less than the action items. A Start/Stop/Continue with three actionable items beats a Sailboat with eight.
How long and how often
The Scrum Guide caps retrospectives at three hours for a one-month sprint — so roughly 45–90 minutes for a two-week sprint. In practice, most well-run retros on two-week sprints finish in 45 minutes. If yours regularly runs over, the discussion-to-action ratio is off: too much talking, not enough deciding.
Hold one at the end of every sprint. Skipping a retro when "we're busy" is precisely when the patterns you'd have caught compound into the next sprint.
FAQ
What's the difference between a sprint review and a sprint retrospective? A sprint review is about the product — you demo what was built and gather stakeholder feedback. A retrospective is about the team and the process — you examine how you worked, not what you shipped. Both happen at the end of the sprint; the review comes first.
How many action items should a sprint retro produce? Three or fewer. Each one needs a single owner and a clear done-condition. A retro that produces eight action items will complete zero of them — the list becomes background noise by the next standup.
Who should attend a sprint retrospective? The development team and the Scrum Master. The Product Owner is optional in most frameworks — their presence can shift the conversation toward product decisions instead of process ones. Stakeholders and external guests generally don't attend.
What are the most common retrospective formats? Start / Stop / Continue is the most widely used. Mad / Sad / Glad surfaces team-health issues. 4Ls (Liked, Learned, Longed For, Lacked) works well for deeper reflection after a rough sprint. Rotate formats every few sprints to keep engagement from dropping.
How do you make action items actually happen? Name one owner per item (not "the team"), write the done-condition before the meeting ends, and put the items somewhere visible — the top of your sprint planning doc, a pinned Slack message, or a shared link the team can check without opening Confluence. If the action item isn't findable in 10 seconds at standup, it won't get done.
Can remote teams run effective retros? Yes — the format translates well. The challenge is async participation: not everyone processes and types at the same speed in a video call, so dominant voices dominate. One fix: send the retro doc link 30 minutes before the meeting and let people pre-fill comments anonymously, then discuss in the call. Drafty's guest commenting works without an account, so nobody needs to be added to a workspace.