Sprint retrospectives are supposed to surface real issues and drive improvement. But too often they turn into one person's monologue about deployment pain points, or a polite silence where no one wants to be the first to speak.
The problem isn't your team. It's the format.
When you go around the room asking "What went well?", the loudest or most senior person sets the tone. Everyone else nods along. The quiet developer who noticed the flaky UI tests never says a word.
You need a structure that gives every person equal airtime, keeps input private until everyone has written theirs, and turns raw input into a short list of actions. That structure has five phases: collect, reveal, vote, discuss, and act.
Why the standard retro format breaks
Traditional retros rely on open discussion from the start. This works well only if your team already has high psychological safety. Most teams don't.
Here's what usually happens:
- The first speaker frames the conversation. If the senior developer starts talking about architecture debt, the rest of the session revolves around that. A tester's issue about confusing acceptance criteria stays unspoken.
- People self-censor. They wonder "Is my issue important enough?" and decide it's not.
- Groupthink sets in. The team converges on the same few topics without surfacing deeper problems.
- Action items are vague. Without a vote, the team picks a "nice to have" improvement that no one owns.
The solution is to separate input from discussion. Collect ideas in private, then reveal them all at once. That way every voice is on the board before anyone speaks.
The 5-phase retrospective structure
This format works for teams of 3 to 15 people. Plan about 45 minutes for a two-week sprint.
Phase 1: Collect (5–7 minutes)
Each person writes their thoughts down, one card per thought, in the board's columns. With the classic format those are:
- Went well: what should we keep doing?
- Could improve: what slowed us down or caused friction?
- Ideas: what could we try next sprint?
The critical rule: no one sees anyone else's cards until the facilitator reveals them.
This phase is silent. If someone starts commenting on a card, gently remind them: "We'll discuss everything in a few minutes. Keep writing."
Phase 2: Reveal (2 minutes)
The facilitator reveals all cards at once, and everyone sees the full board.
This is the moment the team sees what their colleagues actually think. Often the most important items are surprises: things the Scrum Master or product owner had no idea were bothering the team.
Phase 3: Vote (3 minutes)
Each person gets three votes, for up to three different cards.
Voting turns a long list of individual concerns into a ranked list. The cards with the most votes are what the team collectively thinks matters most, not what the loudest person mentioned.
Phase 4: Discuss (20 minutes)
Now you talk. But you don't discuss every card. Start with the highest-voted cards and work down until time runs out.
For each card:
- Read it aloud.
- Ask the person who wrote it to elaborate, only if they want to.
- Ask the group: "Is this something we can change?"
- If yes, agree on an action. If no, note it as a constraint and move on.
The key discipline is start with the votes, not the loudest voice.
Phase 5: Act (5–10 minutes)
A retro without action items is just a complaint session. For each card you discussed, agree on one concrete action:
- What exactly will we do?
- Who owns it?
- When do we check it? (Usually: at the next retro.)
Keep it to one to three actions. They go into your backlog or sprint like any other work, so they don't get lost in a document.
Worked example: Northwind Mobile Banking, Sprint 13
Northwind Mobile Banking is a four-person team: Sam, Priya, Tom and Lena. Here is how their Sprint 13 retrospective went, phase by phase. The screenshot above shows their board during the discussion.
Collect
Everyone wrote their cards without seeing the others':
- Went well: "Pairing on the payments API saved us days" (Priya), "Release went out without a hotfix for the first time" (Tom), "Design reviews earlier in the sprint" (Lena).
- Could improve: "Flaky UI tests block merges" (Tom), "Too many stories still 'almost done' on the last day" (Sam), "Requirements for limits changed mid-sprint" (Priya).
- Ideas: "Quarantine flaky tests in a separate CI job" (Sam), "Swarm on the top story before starting new ones" (Lena).
Reveal
When Sam revealed the board, the team saw that two cards pointed at the same problem: Tom's complaint about flaky tests and Sam's idea to quarantine them. Nobody had raised it in the daily stand-ups.
Vote
Four people, up to three votes each. The top of the board:
| Card | Votes |
|---|---|
| Flaky UI tests block merges | 3 |
| Quarantine flaky tests in a separate CI job | 3 |
| Too many stories still "almost done" on the last day | 2 |
| Swarm on the top story before starting new ones | 1 |
Discuss
The two flaky-test cards were really one topic, so the team took them together. Tom explained how often a failing UI test blocked a merge that had nothing to do with it. The group agreed that moving the unreliable tests into a separate CI job would unblock merges without hiding the failures.
With the time left, they looked at "almost done" stories. Lena's idea fits it: swarm on the top story before anyone starts a new one.
Act
The team agreed on two actions:
- Move the flaky UI tests into a separate CI job (owner: Tom).
- Try swarming on the top story for one sprint and check the result at the next retro (owner: Sam).
Two actions, each with an owner, both small enough to finish in one sprint.
Common mistakes and how to avoid them
Letting the discussion drift back to the loudest person
Even with a structured retro, one person can dominate the discussion. The facilitator's job is to redirect: "Let's stay with the flaky tests card for now. We'll get to your point if there's time."
Skipping the vote
Some facilitators think voting is unnecessary. "We know what the problems are," they say. But you don't. The vote shows the collective priority, not the most recent complaint.
Too many action items
Limit action items to one to three per retro. If you list ten, none will get done.
Not following up
An action item without a check-in is useless. Start each retro by looking at the previous retro's actions: done, still open, or dropped on purpose?
Making the retro optional
If the retro is optional, the people who need it most will skip it. Make it a fixed part of the sprint.
How AllScrum supports the 5-phase retro
AllScrum has a retrospective board built around this structure:
- Start it from Meetings. Start retrospective creates a board and a linked meeting with the Retro label, so the results stay with the project.
- Pick a template. Classic (Went well, Could improve, Ideas), Mad · Sad · Glad, Liked · Learned · Lacked, or Start · Stop · Continue.
- Cards stay hidden until the reveal. By default even the facilitator can't see other people's cards before the reveal. People can also keep private drafts and publish them when they're ready.
- Three votes per person, for up to three different cards. In the discussion, each column is sorted by votes.
- The facilitator moves the board through the phases: collect, reveal, vote, discuss and finish.
- Guests and anonymity. Invite people without an account through a guest link, or turn on anonymous mode so nobody's name is shown on their cards.
- Actions become tasks. In the linked meeting the facilitator writes notes and creates tasks with owners. Finish retrospective adds the feedback and vote totals to the meeting notes.
Checklist for your next retro
- Look at the previous retro's actions first.
- Set a time for each phase: collect (7 min), reveal (2 min), vote (3 min), discuss (20 min), act (10 min).
- Remind everyone to write silently during collect.
- Reveal all cards at once.
- Give each person three votes.
- Discuss cards in vote order, highest first.
- Agree on one to three actions, each with an owner.
One retro with this structure will feel different from the ones you've run before. Try it in AllScrum for free at allscrum.com.