Sprint Retrospective Meeting: Format, Questions and Notes

For the fourth sprint in a row, Dana's team wrote the same sticky note: "Staging environment is flaky." Everyone nodded. Everyone agreed it hurt. And for the fourth sprint in a row, nobody fixed it, because nobody had been asked to. (Dana's team is a composite, not a real team.)

If that sounds familiar, the problem isn't the format of your retrospective meeting. It's what happens after it. A good retro produces two or three changes with a name and a date next to each, and checks them at the start of the next one.

This guide covers what the Scrum Guide says, a five-step format for a 60-minute retro, four formats, 20 questions sorted by stage, a one-page notes template with a filled example, and a rule that turns retro notes into finished action items.

What is a retrospective meeting?

A retrospective meeting is a short, regular meeting where a team looks back at how it worked during the last stretch of work and agrees on a few changes for the next one. In Scrum it's called the Sprint Retrospective, and it's the last event of every sprint.

The 2020 Scrum Guide puts its purpose plainly: "to plan ways to increase quality and effectiveness." The team inspects "individuals, interactions, processes, tools, and their Definition of Done" and picks the most helpful changes. The guide adds that the most impactful improvements "may even be added to the Sprint Backlog for the next Sprint."

The twelfth principle of the Agile Manifesto reads: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

You don't need to write software to use it. Sales teams run retros after a quarter or a lost deal (see our win-loss analysis guide for that version).

Who attends and how long it takes

In Scrum, the whole Scrum Team attends: the Developers, the Product Owner and the Scrum Master. The Scrum Master usually facilitates. Managers outside the team should stay out unless invited, because people speak less freely with an audience.

The Scrum Guide sets a maximum: the Sprint Retrospective "is timeboxed to a maximum of three hours for a one-month Sprint," and shorter sprints get shorter retros. A common practice (not a Scrum rule) is to scale it down in proportion:

Hold it after the Sprint Review and before the next Sprint Planning, so agreed changes go straight into the plan. Our meeting cadence guide shows how to space it among your other recurring meetings.

A five-step retrospective meeting format

Most facilitators run some version of the five stages Esther Derby and Diana Larsen described in their book Agile Retrospectives (2006). This run sheet adapts them for a 60-minute retro after a two-week sprint: it adds a review of last retro's actions and puts deciding and closing in one slot.

1. Set the stage (5 minutes). State the goal and the timebox. Ask everyone for one word that describes the sprint, so every voice is heard early.
2. Review last retro's actions (5 minutes). Done, in progress, or dropped? This is the step that fixes Dana's problem.
3. Gather data (15 minutes). Use one of the formats below. Everyone writes cards silently first, then reads them out.
4. Generate insights (15 minutes). Group similar cards, dot-vote, and talk about the top two or three themes. Ask why it happened, not who did it.
5. Decide what to do and close (20 minutes). Agree on no more than three actions, each with one owner and a check date. Read them back aloud. Close with a quick rating of the retro itself.

You can run all five steps on a whiteboard with sticky notes. Or use our free retrospective template: pick a format, add cards, dot-vote, assign actions and print the result, all in the browser.

Four retrospective formats and when to use each

Rotate formats every few sprints so answers don't go stale. These four cover most situations:

A composite example: a field sales team switched to 4Ls after a tough quarter. The "Longed for" column surfaced something the old format never had: reps wanted a colleague's notes from earlier visits before calling on the same account. That became the quarter's one action.

Retrospective questions, sorted by stage

Twenty questions you can borrow. Pick two or three per stage, not all of them.

Set the stage

1. In one word, how did this sprint feel?
2. On a scale of 1 to 5, how much energy do you have left?
3. What's one thing you want from the next 60 minutes?

Review last retro's actions 4. Which of last sprint's actions did we finish? 5. Which ones stalled, and what got in the way? 6. Is any open action no longer worth doing?

Gather data 7. What went well that we should keep doing? 8. Where did we lose the most time? 9. What surprised you this sprint? 10. When did you feel stuck, and who could have helped? 11. What did we promise that we didn't deliver?

Generate insights 12. Why do you think that happened? 13. Is this a one-off or a pattern we've seen before? 14. What's the smallest change that would have prevented it? 15. What would we do differently if we had to repeat this sprint tomorrow?

Decide what to do and close 16. Which one change would make the biggest difference next sprint? 17. Who will own it, and when will we know it worked? 18. What will we stop doing to make room for it? 19. Is there anything we need from outside the team? 20. How useful was this retro, from 1 to 5?

Retrospective meeting notes: a one-page template

Retro notes should be short: the themes, the decisions and the actions. Copy this template:

RETROSPECTIVE NOTES
Team:              Sprint / period:          Date:
Facilitator:       Format used:              Attendees:

1. LAST RETRO'S ACTIONS
   Action | Owner | Status (done / in progress / dropped) | Note

2. WHAT WE SAW (top themes after voting, 3 to 5 lines)

3. WHY (one line per theme)

4. ACTIONS FOR NEXT SPRINT (max 3)
   Action | Owner | Check date | Where it lives (backlog, board, doc)

5. RETRO RATING (average 1-5) and one comment

Here's the same template filled in for Dana's team (a composite example):

RETROSPECTIVE NOTES
Team: Payments squad    Sprint: 41 (two weeks)    Date: October 9
Facilitator: Omar (rotating)    Format: Start/Stop/Continue    Attendees: 7

1. LAST RETRO'S ACTIONS
   Pair on code reviews twice a week | Lin | Done | Review wait time down
   Fix flaky staging environment | (no owner) | Dropped | Raised 4 sprints in a row

2. WHAT WE SAW
   - Staging failed on 3 of 10 days; 2 releases slipped
   - Pairing on reviews worked; keep it
   - Late scope changes from the Product Owner on day 8

3. WHY
   - Staging: nobody owns it; it sits between two teams
   - Scope: stakeholder demo moved up, nobody told the team until day 8

4. ACTIONS FOR NEXT SPRINT
   Own staging fixes; add to Sprint Backlog | Priya | Oct 23 | Sprint Backlog
   PO shares stakeholder dates at Sprint Planning | Ana | Oct 13 | Planning agenda
   Keep review pairing | Lin | Oct 23 | Team board

5. RETRO RATING: 4.1 / 5: "First time staging has an owner."

Notice what changed: the staging fix has a name, a date and a place in the Sprint Backlog, as the Scrum Guide suggests. For other meetings, use our meeting notes template.

Want the notes without typing during the retro? Put ParrotNotes on the table and get a summary and action items when the meeting ends. Try ParrotNotes free.

Turning retro notes into action items that get done

Retros fail quietly when actions are vague ("improve communication") or ownerless ("we should"). Four rules:

• One owner per action. A name, not "the team." The owner makes sure it happens.
• A check date. Usually the next retro. Write the date down, not "next sprint."
• A visible home. The Sprint Backlog or the team board, where daily work happens. Actions left only in the notes are forgotten by Wednesday.
• No more than three. A team that commits to eight changes finishes none.

Then open the next retro by reviewing them (step 2 of the run sheet). That habit turns a venting session into a loop. For a system that chases actions across all your meetings, read our guide to action items tracking. When a retro produces a real decision, like changing your Definition of Done, log it in a decision log so new team members can find out why.

Should you record the retrospective?

Recording a retro helps the facilitator stay present and capture every action. But retros depend on honesty, so ask first: say why you want to record, what you'll keep and who will see it. Get everyone's agreement, and stop if anyone objects.

Consent rules also vary by location; our guide to one-party consent states explains the US basics.

If the team agrees, ParrotNotes records the retro on a phone or Mac in the room, with no meeting bot. You get a transcript, a summary and the action items, ready to paste into the template above. A week later, ask the transcript "What did we agree about staging?" On Pro, it handles 99+ languages with translation, and AI search finds what was said across every past retro.

Make your next retro the one that sticks

A retrospective meeting is worth the hour only if it changes something. Set the stage, review last sprint's actions, gather data with a format that fits, find the why, and leave with three actions or fewer, each with an owner and a date. Write it on one page, and start the next retro by checking it. And keep it blame-free: talk about events and processes, never people.

Dana's team didn't need a new format. They needed a name next to "fix staging." Two sprints later, the sticky note was gone.

Spend your next retro facilitating, not typing. ParrotNotes captures the conversation in the room and hands you the summary and action items when you're done. Download ParrotNotes free and try it at your next retrospective.