Sprint Retrospective Template (Free, Fillable + Example)

Most teams hold a retrospective, collect sticky notes, and then do nothing with them. A few weeks later the same problems show up again — late deployments, unclear requirements, too much context switching — and the team repeats the ceremony with zero change. The retrospective is not the problem. The problem is that the meeting has no structure for turning discussion into owned, dated, and tracked actions. A sprint retrospective template fixes that: it gives the facilitator a fixed agenda, the team a way to sort feedback, and the work a place to live after the meeting ends.

This article gives you a complete, copy-paste-ready sprint retrospective template, a filled-in example with real numbers, the most common retrospective formats and when to use each, where to find free templates, and the mistakes that make retrospectives worthless.

Quick Answer: What Should a Sprint Retrospective Template Include?

A sprint retrospective template should include four blocks: (1) what went well, (2) what didn’t go well, (3) team and delivery metrics for the sprint, and (4) an action table with a small number of prioritized improvements, each with an owner and a follow-up date. The Scrum Guide describes the retrospective as the event where the Scrum Team inspects how the last Sprint went and plans improvements to increase effectiveness — so the action items, not the discussion, are the real deliverable. Keep the action list small (three to five items) and review each one at the next retrospective before adding new ones.

What Is a Sprint Retrospective, Really?

A retrospective is the last Scrum event of the sprint. Its purpose, in the words of the Scrum Guide, is to inspect how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done — and to identify what went well, what could be improved, and agree on changes to implement. It is timeboxed: three hours for a one-month sprint, scaled proportionally for shorter sprints.

Two things distinguish a good retrospective from a team meeting with pizza:

• It focuses on process, not people. The discussion targets how the team works together, not who failed.
• It ends with a concrete plan. The entire ceremony exists so the team can agree on a few changes it will actually try in the next sprint.

If the meeting does not produce dated, owned actions, it produced conversation — not a retrospective.

The Free Sprint Retrospective Template (Copy-Paste Ready)

Copy the structure below into Google Docs, Notion, a Confluence page, a whiteboard, or your project management tool. Fill in every bracket. Keep the whole thing on one page if you can.

1. Retrospective Basics

• Sprint number: ____
• Dates: Start ____ | End ____
• Sprint goal: ____
• Facilitator: ____ | Participants: ____ (list names)
• Format this sprint: ____ (e.g., Start-Stop-Continue, 4Ls, Mad-Sad-Glad, Sailboat)
• Retro length: ____ minutes (target: 3 hours for a 1-month sprint, scaled down)

2. What Went Well

3. What Didn’t Go Well

4. Sprint Metrics (optional but powerful)

• Planned vs completed: ____ story points / tasks planned → ____ completed
• Sprint goal met? yes / partially / no
• Escaped defects: ____ | Production incidents: ____
• Unplanned work absorbed: ____ hours

5. Actions & Experiments (the deliverable)

Rule: maximum 5 actions. Fewer, owned, and completed beats a list of 15 good intentions.

6. Team Health Check (rate 1–5)

Filled-In Example: A Retrospective With Real Numbers

Here is a condensed filled version of the template for a 4-week sprint of a 6-person development team (Sprint 14).

• Sprint goal: Ship the payment-v2 feature to 20% of customers.
• Metrics: 32 story points planned, 28 completed. Sprint goal met partially — feature shipped to staging but not to production. 3 escaped defects found after merge. 1 production incident (slow checkout) absorbed 14 hours of unplanned work.
• What went well: the QA/dev pairing on the checkout flow caught 11 bugs before merge; the daily standup stayed under 15 minutes for the whole sprint; the mid-sprint demo to the product owner killed a wrong assumption early.
• What didn’t go well: two big stories were delivered 2 days late because acceptance criteria arrived mid-sprint; deployment day was spent on an unrelated infrastructure fix that nobody had flagged.
• Actions produced:

1. Write acceptance criteria for each story during sprint planning (owner: Product Owner, due: before Sprint 15 planning).
2. Add “deploy + rollback” to the Definition of Done with a 15-minute rollback test (owner: Lead Dev, due: Sprint 15, week 1).
3. Move the mid-sprint demo to a fixed slot every Wednesday 2pm (owner: Scrum Master, due: next sprint).

• Team health: clarity 4, workload 3 (flagged as tight), communication 5, pace 3.

Three actions, three owners, three dates. At the Sprint 15 retrospective, the team checks these off first — that loop is what changes behavior.

Which Retrospective Format Should You Use?

There is no “best” format. Rotate between two or three so the team does not get stuck in the same discussion shape every sprint. The template above works with any format — the format only changes how you sort the “went well / didn’t go well” notes in sections 2 and 3.

Where Can You Find Free Sprint Retrospective Templates?

You do not need to build from scratch. Real, reputable sources include:

• Atlassian Confluence — a free 4Ls retrospective template plus a large project-management template gallery; opens straight into a shared Confluence page. Trade-off: best inside the Atlassian ecosystem, and a page is still a document unless you copy actions into a task tool.
• Trello — free retrospective board templates (list-based: Went Well / To Improve / Action Items) that double as a live tracking board. Trade-off: simple, but no built-in velocity or metrics.
• Asana — free retrospective project templates that turn actions into assigned tasks with due dates immediately. Trade-off: better for the action-tracking half than for the discussion half.
• Miro and Notion — template galleries with visual retrospective boards and docs. Trade-off: great for facilitation, but you will still transcribe the outcomes somewhere that tracks completion.
• Dedicated retro tools (easyretro, TeamRetro, Retrium) — built for the ceremony with anonymous voting and fun formats. Trade-off: subscription cost and yet another tool; they usually integrate with or export to Jira for the actions.

The pattern to notice: every source gives you either a great discussion surface or great action tracking — rarely both. That split is why the template’s section 5 (actions with owners and dates) is the part you must carry into your real work tracker.

How Do You Make Retrospective Actions Actually Happen?

A retrospective action list that lives in a document is a wishlist. Here is the workflow that closes the loop:

1. During the retro, nominate the top 3–5 actions and assign an owner and a date while everyone is in the room — not afterward.
2. Move each action into your task tracker the same day. Each action becomes a task with an owner, due date, and a link back to the retrospective.
3. Treat actions as normal work. They compete with sprint work, so the team must deliberately budget for them (for example, 10% of capacity).
4. Open the next retrospective by reviewing last sprint’s actions. What got done, what didn’t, and why. This review is the accountability engine — without it, actions silently die.

Scenario 1: A 6-person dev team with a velocity drop

After 4 weeks, planned velocity dropped from 34 to 26 story points. The retro’s 5 Whys found over-commitment plus mid-sprint scope adds. The team agreed to plan 10% below capacity and freeze scope after planning. Two sprints later, velocity is back to 31 and the mid-sprint scope adds are down from 6 stories to 1. One owned action changed a full sprint cycle.

Scenario 2: A 10-person remote team across 3 time zones

The retro (45 minutes) used a shared board so async members added notes before the meeting. Actions: (1) move handoff documentation to the shared space, (2) schedule the standup at a time that overlaps all zones (1pm UTC), (3) run a demo every Friday. All three were tracked as tasks. Two of three completed within the next sprint; the third was re-planned. The team now opens each retro by checking the previous action board — nothing disappears.

Scenario 3: A 5-person marketing team adopting retros outside Scrum

A non-Scrum team runs a monthly retrospective with the same template, using Start-Stop-Continue. In one session they produce 11 improvement ideas; the facilitator caps the action list at 4. Two actions survive the month: a content review checklist and a Monday publishing schedule. Even without Scrum, the template’s action loop is what makes the ceremony useful.

Common Mistakes

Mistake 1: No actions, or too many actions. A retro that ends without owned actions is a meeting, not a process-improvement tool. A retro that produces 15 actions produces zero — the team can’t do them all.

Mistake 2: Blame-focused discussion. When the room spends the time deciding whose fault a bug was, people stop speaking honestly. Redirect from “who” to “what process let this happen.”

Mistake 3: Using the same format forever. After a few sprints the Start-Stop-Continue pattern gets repetitive and the discussion goes flat. Rotate formats deliberately.

Mistake 4: Skipping metrics. A retro with only opinions misses the signal — like a velocity drop from 32 to 28 story points or 3 escaped defects. The metrics section turns feelings into data.

Mistake 5: Letting it become a standup or status report. The retrospective is about how the team works together, not what each person shipped.

Mistake 6: Actions reviewed only once, next retro, in a rush. Action review deserves the first 10 minutes of the meeting, with a clear answer for every unfinished item.

Know This Before You Choose

• The template is 30% meeting structure and 70% action management. Judge any template by what it does with the actions after the meeting, not by how pretty the board is.
• Keep it on one page. A retrospective that needs a 6-page document to explain itself will not be filled in next sprint.
• Cap actions at five. Completion rate beats ambition; three completed actions every sprint compounds into real change over a year.
• Owners must be people, not teams. “QA team” owns nothing; “Mariana” owns the regression checklist.
• Vary the format to keep the signal honest. The moment a retro feels like a ritual, its output quality drops.

How Can You Run This Template in Doitify?

The step that makes or breaks a retrospective is what happens to the action items after the meeting. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. In Doitify you can keep the retro’s outcome as tasks and sub-tasks with owners, due dates, and checklists, attach the meeting notes and the retrospective document to the sprint, and track each action on a Kanban board until it is done — with the next retrospective opening straight onto the list of unfinished actions. You can also track sprint work with sprints and backlogs, milestones, and reminders, and pull work/performance reports to bring real metrics into the meeting. If your problem is retro discussions that evaporate after the meeting, that is exactly the gap this workflow closes. Explore project management templates to see how the whole agile workflow fits together.

Conclusion

A sprint retrospective template is only as good as the loop it creates: structured discussion → 3–5 owned actions → tracked completion → review at the next retro. Use the fillable template in this article, pick a format that fits the sprint (Start-Stop-Continue for beginners, 4Ls or Sailboat for depth, 5 Whys for recurring problems), and carry the actions into a tracker the same day. The team that reviews last sprint’s actions for the first 10 minutes of every retrospective is the team whose retrospectives stop being ceremonies and start changing how they work.