Quick answer: To run a retrospective people actually speak up in, have everyone write silently before anyone talks, read a short no-blame statement at the start, and check how safe the room feels. Group and vote on the notes, then leave with one or two actions that each have a named owner. Change the format every few sprints so it never turns into a ritual.
Most retros don't fail because the format is wrong. They fail because the same three people talk, everyone else nods, and the action list from last time never gets mentioned again. After a few sprints of that, people stop bothering. They show up, type "communication could be better" on a sticky note, and wait for it to end.
I've run a lot of these, for engineering teams and for teams that have never heard the word "sprint". The fixes below are the ones that made the biggest difference, roughly in the order I'd try them.
What is a sprint retrospective actually for?
The Scrum.org explanation of the sprint retrospective is short and plain: the team looks at how the last sprint went across people, interactions, processes and tools, and plans ways to improve quality and effectiveness. The Scrum Guide caps it at three hours for a one-month sprint, and shorter sprints get a shorter slot. For a two-week sprint I rarely go past an hour.
The word that matters there is "improve". A sprint retrospective isn't a status meeting, a venting session or a performance review. If nothing changes in the next sprint, the retro didn't do its job, however good the conversation felt.
You don't need to run Scrum to get value from this. A marketing team closing a campaign, a support team after a rough week, or a project team after a launch can all run a retrospective the same way. The steps below assume a team of four to ten people.
Why do people stay quiet in retros?
Usually for one of four reasons, and they need different fixes:
- It doesn't feel safe. Someone senior is in the room, or the last person who raised a real problem got a defensive answer.
- Loud people go first. Once the first two opinions are out, everyone else anchors on them or decides there's nothing to add.
- Nothing happened last time. If the previous actions quietly died, speaking up feels pointless. Following up on them is part of holding people accountable without micromanaging.
- They're bored. The same "what went well, what didn't" board, every two weeks, for a year.
Amy Edmondson's research on teams is the classic reference for the first one. Her 1999 study on psychological safety and learning behavior described psychological safety as a shared belief that the team is safe for interpersonal risk taking, and found it went hand in hand with teams actually learning from their work. You can't announce psychological safety into existence. You can, however, stop doing the things that destroy it.
How do you set up a retro so it feels safe?
Start before the meeting. Tell people what the format will be, and that notes from the session will capture themes and actions, not who said what. That one sentence changes how much people are willing to write.
Then open with the Retrospective Prime Directive, from Norm Kerth's book on project retrospectives. Martin Fowler has a short piece on why teams read it aloud. The usual wording is:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
It can feel a bit cheesy the first time. Read it anyway. The point is to move the conversation from "who messed up" to "what made that mistake easy to make".
Run a quick safety check
Ask everyone to rate, anonymously, how comfortable they feel talking openly today, from 1 (I'll keep my head down) to 5 (I'll say anything). A poll in your video tool or folded paper works fine. If most answers are 1s and 2s, don't push on with the usual board. Talk about that instead, or keep the session to a lighter format and follow up one-to-one.
Think hard about who's in the room
If a director or a client sits in, people will edit themselves. That's not a character flaw, it's normal. Keep retros to the team doing the work, and share the outcomes upward afterwards.
How do you run a retrospective step by step?
Here's the 60-minute plan I fall back on for a two-week sprint. Adjust the minutes, keep the order.
- Check-in (5 min). One word or one sentence each on how the sprint felt. Everyone speaks once in the first five minutes, which makes it much easier to speak again later.
- Review last retro's actions (5 min). Did they happen? If not, why not? Be honest here. If the answer is "no" three retros running, people notice, and they stop writing real notes.
- Silent writing (8-10 min). Everyone writes their own notes, alone, with no talking. One idea per note.
- Read out and group (10 min). Each person reads theirs out briefly. The facilitator clusters similar notes into themes.
- Dot vote (5 min). Three votes each. Pick the top one or two themes.
- Discuss the top themes (15-20 min). Ask "what's underneath this?" before jumping to fixes.
- Agree actions (5-10 min). One or two, each with one owner and a date. Say them out loud and write them where the team works.
Silent writing is the single biggest change for quiet people. It gives introverts time to think, it stops the first speaker from setting the agenda, and it means every person's view is on the board before the discussion starts. If you only change one thing about how you run a retrospective, change this.
Which retrospective format should you use?
Any retrospective format works for a while. None works forever. Rotate every three or four sprints so people have to think rather than repeat last month's notes.
- Start, stop, continue. Good default for new teams. Concrete and easy to turn into actions.
- 4Ls (liked, learned, lacked, longed for). Atlassian has a free 4Ls retrospective template. "Longed for" tends to surface things people want but don't feel they can ask for.
- Sailboat. Wind (what pushed us), anchors (what held us back), rocks (risks ahead). The metaphor helps teams who find direct criticism awkward.
- Timeline. Draw the sprint as a line and have people mark highs and lows. Great after an incident or a messy launch, because it rebuilds a shared memory of what happened.
- Single question. "What's one thing that would make the next sprint easier?" Useful when everyone's tired and you only have 30 minutes.
My opinion: skip the elaborate themed retros with superheroes and movie posters. They're fun once. After that they take facilitator prep time and add nothing the sailboat doesn't already do.
What retrospective questions get honest answers?
Vague questions get vague answers. "What went wrong?" invites "communication". Sharper retrospective questions get real material:
- What did you wait on this sprint, and for how long?
- What surprised you?
- Where did you work around the process instead of with it?
- What would you tell a new teammate to watch out for?
- Which meeting could we have skipped?
- What's one thing you did that nobody noticed?
When someone does write "communication", don't let it sit there. Ask for the specific moment: which message, between whom, on which day. The specific version is fixable; the abstract one never is.
How do you turn retro action items into real change?
This is where most teams lose people. They leave with eight actions, nobody owns any of them, and two weeks later the retro opens with the same complaints. People notice. That's when the honest notes stop.
A few rules that help with retro action items:
- One or two actions, not eight. A small change that happens beats a big plan that doesn't.
- One owner per action. "The team" is not an owner. If two people share it, nobody owns it.
- A date or a sprint. "By Thursday" or "during sprint 15", not "soon".
- Put it where the work lives. If your team plans in Jira, add the action to the next sprint backlog so it competes with real work instead of hiding in a doc.
- Open the next retro with it. That's step 2 above, and it's not optional.
We've written more about this pattern in why action items don't get done, and the same causes show up in retros. For the notes themselves, the basics in how to take meeting notes apply: capture themes, decisions and owners, not a transcript of every comment.
Should you record a retrospective?
Honestly, often not. A retro depends on people saying slightly uncomfortable things, and a recording can make them more careful. My rule: ask the team, and if anyone hesitates, don't record. Capture the board and the actions instead.
Some teams are fine with it, especially remote teams who want an accurate list of what was agreed without one person typing the whole time. If you do capture it, tell everyone up front and explain who can see the notes. Our guide on recording consent and what to tell participants covers the basics. If bots aren't welcome in the call, a desktop recorder like Acta's desktop app captures it from your own computer, and you can share only the summary and actions rather than the full transcript.
What mistakes kill a retro?
- The manager facilitates and talks most. Rotate facilitation, or borrow a facilitator from another team.
- Solving before understanding. The first fix suggested is usually the one that treats a symptom.
- Skipping the retro "because we're busy". Busy sprints are when you most need one. Shorten it instead.
- Turning it into blame. If a name comes up with an accusation, steer back to the system: what made this likely?
- Only talking about problems. Saying what went well tells people which habits to keep. Give it a few minutes.
If your daily standups are already eating the team's patience, sort those out too (here's how to run a 15-minute standup); our standup and weekly meeting template keeps them short so the retro doesn't become the only place problems surface.
If you capture retros with Acta
If your team does choose to capture retros, Acta can record Zoom, Google Meet or Teams calls and produce a summary with decisions and action items that have owners. It can send those items on to Jira, which is where many product and engineering teams already plan sprints. Acta doesn't use customer data to train AI models. Whether a retro should be captured at all is still the team's call.
Frequently asked questions
How long should a sprint retrospective be?
The Scrum Guide sets a maximum of three hours for a one-month sprint, with shorter sprints getting less. In practice, 45 to 60 minutes covers a two-week sprint for a team of up to ten people.
Who should facilitate a retro?
Ideally not the team's manager. A Scrum Master, a rotating team member or someone from another team works better, because people talk more freely when the person holding the pen doesn't also write their review.
How do you run a retrospective with a remote team?
Use a shared online board, keep cameras optional, and do the silent writing step in the board so everyone types at the same time. Ask people to vote with the board's dot voting rather than out loud, so the result isn't shaped by whoever speaks first.
What if the same issues keep coming up?
That usually means the actions are too big or have no owner, or the problem sits outside the team. Shrink the action to something one person can do in a week, or name who outside the team needs to hear it and who will tell them.
How many action items should a retro produce?
One or two. More than three and they compete with sprint work and quietly get dropped.
If you want a summary and owned action items after each call without writing them up yourself, you can try it on the 15-day free trial.
