Retro Rabbit

Template

What Went Well Retrospective: The Four-Question Template

Run a What Went Well retro live or async over a sprint: the 4 questions, 12 example prompts, a 45-minute agenda, good action items and a free template.

Retro Rabbit TeamUpdated

Columns in this template

  • โœจ What went well?
  • ๐Ÿ’” What didnโ€™t go well?
  • ๐Ÿ“˜ What did we learn?
  • โ“ What puzzles us?
On this page (10 sections)
  1. The four columns
  2. When to use it (and when not to)
  3. How to run it live (45 minutes)
  4. How to run it async over a sprint
  5. 12 example prompts
  6. Facilitator tip and a common pitfall
  7. How AI helps with this format
  8. Example action items
  9. Use this template in Retro Rabbit
  10. Related formats

The What Went Well retrospective asks four questions about the sprint that just ended: What went well? What didn't go well? What did we learn? What puzzles us? It's the default format in Retro Rabbit and the most widely used one anywhere. Nobody needs it explained, and the last two questions catch what two-column boards drop.

The four columns

ColumnWhat goes hereExample note
โœจ What went well?Wins, things that worked, help someone gave"Pairing on the payments migration caught two bugs before code review."
๐Ÿ’” What didn't go well?Problems, friction, misses"Staging was down most of Wednesday and nobody knew who owned it."
๐Ÿ“˜ What did we learn?New knowledge: technical, about users, about how you work"Feature flags let us ship the checkout change without a release freeze."
โ“ What puzzles us?Open questions nobody can answer yet"Why do our estimates for API work keep landing at twice the size?"

The format is close to Norm Kerth's four key questions from Project Retrospectives (2001), the book that also gave us the Retrospective Prime Directive. Kerth asked "What should we do differently next time?" where this version asks "What didn't go well?".

Why four columns beat two. "What did we learn?" turns opinions about the past into knowledge the team keeps. "What puzzles us?" lets people say "I don't understand this", and those notes often point to next sprint's problems.

When to use it (and when not to)

Use it when:

  • it's a new team's first retro, or a new team member's first
  • the sprint was a mix of good and bad with no single dramatic event
  • you want learnings written down after a release or a migration

Pick something else when:

  • you've run it five sprints in a row and the notes are repeating. Try Sailboat or 4Ls for a different angle.
  • the team is upset about something. Start with Mad Sad Glad so feelings are heard before you analyze anything.
  • everyone already knows what's wrong and needs to decide what to change. Use Start Stop Continue.
  • a serious incident needs a root-cause analysis. Run an incident review first, then use the retro for team-level follow-ups.

How to run it live (45 minutes)

TimeStep
0โ€“5 minReview last retro's action items
5โ€“15 minSilent writing: add notes to all four columns
15โ€“22 minGroup similar notes and name the groups
22โ€“27 minVote: three dot votes each
27โ€“42 minDiscuss the top three groups
42โ€“45 minAgree on one to three action items, each with an owner
  1. Open with follow-through. In the Action Items panel, go through the Previous Retro tab: done, in progress, or drop it. If nothing got done, that's your first topic.
  2. Write in silence. Set the shared timer for 10 minutes so the loudest person doesn't set the agenda. If notes were added during the sprint, people only add what's missing.
  3. Read the wins out loud. Use the All Topics menu to show only "What went well?" and read every note.
  4. Group. Drag related notes onto each other. Three notes about staging are one problem, not three.
  5. Vote and sort. Turn on dot voting in the Team Room settings, then sort by Most Votes.
  6. Discuss, then decide. About five minutes per group: what happened, why, and what would prevent it. Write action items as you go, not at the end.

How to run it async over a sprint

This format works especially well async, because the main thing that ruins it is recency bias: by the end of the sprint people remember last Thursday and forget the first week.

  1. Day 1: open the board when the sprint starts. In Retro Rabbit, clicking Start New Retro after your last meeting opens the next board straight away. Ask the team to add a note the day something goes well or badly.
  2. During the sprint: people add notes on the web board, in the Team Room's Quick Notes box, or with /retro your note if you've connected Slack. Switch off Show Name to post without your name.
  3. Mid-sprint: the facilitator checks the board. If "What did we learn?" is empty, add one example yourself. People copy what they see.
  4. Two days before the end: ask everyone to fill gaps and vote. Notes are visible as they're added, so people can vote any time.
  5. The day before: the facilitator groups related notes and reads the CarrotIQ summary for themes.
  6. Retro day: hold a 20-minute call that starts at the top-voted groups. Or skip the call: post the top three groups in your team channel, collect proposed actions by end of day, and confirm owners in the morning.

For more on running retros in writing, see How to run an async retrospective.

12 example prompts

Use these to get people writing when the board is quiet. For a bigger bank, see 60 sprint retrospective questions.

What went well?

  1. What would you want us to do again next sprint, exactly the same way?
  2. Who helped you this sprint, and how?
  3. What did we ship that you're proud of?

What didn't go well? 4. Where did you wait on someone or something? 5. What took much longer than we expected, and when did we notice? 6. Which meeting this sprint could have been a message?

What did we learn? 7. What do we know now about our users that we didn't two weeks ago? 8. What did you learn about the codebase that the rest of the team should know? 9. What would you tell a new teammate starting tomorrow?

What puzzles us? 10. What happened this sprint that nobody can explain? 11. What decision was made that you don't understand? 12. What are we assuming that we've never checked?

Facilitator tip and a common pitfall

Tip: give "What puzzles us?" its own five minutes. Puzzles rarely get votes because nobody can act on them yet. Read them out anyway and give each a next step: a timeboxed spike, a question for someone outside the team, or "check again next retro".

Pitfall: "What didn't go well?" eats the meeting. It almost always has the most notes, so it takes over and the wins never get read. Teams that only ever discuss problems end up with retros nobody wants to attend. Timebox each column and always read the wins first. We wrote more about this in how bad retrospectives can sink a team.

How AI helps with this format

On the Pro AI plan (and during the free trial), CarrotIQ does the admin so the facilitator can focus on the conversation:

  • Group names. Drag "staging was down Wednesday" onto "couldn't test the checkout fix" and CarrotIQ names the group, for example "Staging Environment Reliability". Useful when "What didn't go well?" has 15 notes.
  • Summaries. The Sprint Summary has a short summary per column plus an overall one, ready for stakeholders who weren't there.
  • Suggested action items. CarrotIQ Suggest proposes an action from the notes, weighting the most-voted ones. Edit it before saving; the team still decides.

Example action items

A good action item has an owner, a verb, a "done when", and a date you'll check it by.

VagueBetter
"Fix staging""Marcus writes down who owns staging and posts it in the team channel by Friday."
"Better estimates""For the next two sprints, Jun tags every API story with its original estimate so we can compare at the next retro."
"More pairing""Pair on every change to the payments service this sprint. Elena tracks how many PRs that covers."
"Look into the flaky test""Priya timeboxes 4 hours to reproduce the flaky checkout test and reports back at standup on Wednesday."

At the next retro, the Previous Retro tab shows exactly what you agreed, and Old / Unresolved Items shows anything older that's still open. More in retrospective action items that actually get done.

Use this template in Retro Rabbit

  1. Start a 14-day free trial. No card is needed.
  2. Name your team and choose Went well / Didn't go well / Learned / Puzzling as your retro format. It's the default.
  3. Invite your team and start adding notes today, not on retro day.

You can rename columns or add a fifth later in the Team Room settings. Pricing is per team, not per user: see pricing.

Frequently asked questions

What are the four questions in a What Went Well retrospective?

What went well? What didn't go well? What did we learn? What puzzles us? The first two cover results, the third captures new knowledge, and the fourth collects open questions nobody can answer yet. They are close to Norm Kerth's four key questions from Project Retrospectives (2001).

What's the difference between What Went Well and Start Stop Continue?

What Went Well looks back at what happened and why. Start Stop Continue looks forward and asks for changes in behavior. Use What Went Well when you want to understand a sprint, and Start Stop Continue when the team already knows what's wrong and needs to decide what to change.

How long should a What Went Well retrospective take?

About 45 minutes for a two-week sprint with five to nine people. If notes were added during the sprint, you can skip most of the writing time and finish in 30 minutes. The Scrum Guide caps retrospectives at three hours for a one-month sprint and says shorter sprints usually need less.

What goes in the 'What puzzles us?' column?

Anything the team can't explain yet: a flaky test nobody can reproduce, estimates that keep missing, a user behavior that surprised you. Don't try to solve puzzles in the meeting. Turn each one into a next step, such as a spike, a question for someone outside the team, or an item to check at the next retro.

Can you run a What Went Well retrospective asynchronously?

Yes, and it suits async better than most formats. Open the board at the start of the sprint and ask people to add a note when something goes well or badly, not two weeks later. Then group, vote and agree on action items either in a short call or entirely in writing.

Should we always start with what went well?

Usually, yes. Starting with wins gets everyone talking before the harder conversation and makes sure good work is recognized. If the team is upset about something specific, acknowledge it first or switch to Mad Sad Glad for that sprint.

Run this retro in Retro Rabbit

Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.

14-day free trial ยท No credit card