What Went Well, What to Improve, Actions

What is the What Went Well, What to Improve, Actions retrospective?

This format pairs reflection with a strict commitment to action. Teams document what worked, what didn't, and then assign owners to specific follow-ups during the same session. The Actions column isn't optional. If the retro ends without owned actions, the format hasn't been used correctly.

It's a close cousin of Start, Stop, Continue, but with a structural difference: the third column is for commitments, not for celebrating things that worked. That shift is small on paper and significant in practice. Teams that keep generating ideas without follow-through tend to settle on this format because it ends every meeting with a list of names and dates.

When to use it

Run this when discussion isn't producing follow-through. If the team has been doing Start, Stop, Continue for a while and the same items keep reappearing, switch to this format. The Actions column makes it harder to walk out without a real plan. It also works well for teams under a manager or product owner who wants visible commitments coming out of every retro.

When not to use it

Skip it for brand-new teams or teams still building psychological safety. The pressure to commit to actions in front of the group can push junior or quieter team members into agreeing to things they don't actually own. Run a few rounds of Start, Stop, Continue or Mad, Sad, Glad first, then switch when the team is comfortable speaking up. Skip it also for retros where the goal is reflection rather than commitment, like end-of-project retros.

Column prompts

• What went well — Ask what the team should protect from being eroded by the next sprint's pressure. Push past surface answers like "we shipped" and ask what specifically made shipping possible this time.
• What to improve — Ask what cost the team time, energy, or trust. Don't accept "communication" or "process" as cards. Push for the specific moment things broke down.
• Actions — Every card here needs three things: what will change, who owns it, and when it'll be done by. "Improve testing" isn't an action. "Alex to fix the flaky test runner by Friday" is.

Facilitator tips

• Run silent writing on the first two columns before opening discussion. The Actions column comes last and only after the group has voted on which "improve" items matter most.
• Don't let the team write actions for someone who isn't in the room. If the action belongs to a manager, write it as a request and assign someone to follow up.
• Cap actions at three per retro. Two committed actions that ship beat six aspirational ones that don't.
• Start each retro by reviewing the previous sprint's actions. If they didn't get done, that's the first conversation to have, not the last.
• Make actions specific enough that someone outside the room could tell whether they were completed. "Better tests" isn't checkable. "Add CI gate that blocks merge on test failure" is.
• If the same item shows up in "improve" sprint after sprint, run a separate working session on it. The retro isn't where complex problems get solved.

Common mistakes

• The Actions column fills up with vague intent. Every action needs an owner and a date.
• Skipping the review of last sprint's actions. Without it, the team learns that committing here doesn't actually mean anything.
• Assigning actions to the team as a whole rather than a person. If everyone owns it, no one does.
• Treating "what went well" as throwaway. That column is where you find the practices worth defending.
• Generating actions for things outside the team's control. Write a request to the right person instead and treat that as the action.

FAQ