What Went Well retrospective

Two columns, two honest questions: what helped the team reach its sprint outcome, and what got in the way? It is the simplest retrospective there is, and simple is often exactly what a team needs.

What went well

Everything that helped you achieve your sprint outcome

What didn’t go well

Everything that didn’t work for the sprint outcome

Use this template — it's free

What a What Went Well retrospective is

The What Went Well retrospective has two columns: what went well and what didn't go well. The team looks back at the sprint, writes down what helped and what got in the way, then votes and talks through the topics that mattered most.

In ProstoRetro both columns are tied to one thing: the sprint outcome. What went well is everything that helped you achieve it; what didn't go well is everything that worked against it. That anchor is what turns a vague good-and-bad list into a useful one. The new coffee machine may well have gone well, but unless it moved the sprint forward, it belongs in small talk, not on this board.

The format differs from Start Stop Continue in one important way. Start Stop Continue cards are proposals: "start doing X". What Went Well cards are observations: "X happened, and this is what it did to the sprint". That makes it slower to reach actions but better at establishing what actually happened — and teams that skip that step tend to fix the wrong thing.

Why two columns are often enough:

• Nothing to learn. Anyone can take part, including people who have never been to a retro.
• No sorting debates. With two columns nobody spends time deciding whether a card is a "lacked" or a "longed for". The writing time goes into the content.
• Grounded in results. Because every card is measured against the outcome, discussion stays on what changes delivery rather than on general dissatisfaction.
• Fast. Fewer columns mean fewer cards to group and more time for the two or three topics that deserve it.

When to use it, and when not to

What Went Well is a good choice when:

• you are running a team's first retrospective, or your own first one as facilitator;
• the sprint had a clear goal and you want to understand why you did or didn't reach it;
• you are reviewing a single event: a launch, a migration weekend, a hackathon, a big demo;
• you have half an hour and a team that wants to get back to work;
• elaborate formats have started to feel like theater and the team is asking for something plain.

Pick something else when:

• The same problems come back every time. Observations without a push to change get repetitive. KPT keeps a similar shape but adds a Try column for experiments.
• There was no clear sprint goal. Without an outcome to measure against, both columns fill with opinions. Agree on what the goal was first, or choose a format that doesn't need one, such as Mad Sad Glad.
• You want lessons, not only a scorecard. The 4Ls give what the team learned a column of its own, which suits the end of a project better.

The two columns

The board has two columns: What went well and What didn't go well. Before anyone writes, state the sprint outcome out loud so everyone measures against the same thing. If the sprint had no single goal, use the most important thing it was meant to deliver.

What went well: what helped us reach the outcome

Practices, decisions, people, tools and lucky breaks that moved the sprint toward its goal. The test: did it make the outcome more likely? Not just "was it pleasant". Good cards name a cause, not only a result. "The release went smoothly" is a result; "we rehearsed the migration on a copy of production first" is the cause worth repeating.

• Splitting the checkout story in two let us ship the first half on day four
• Product sat in on our channel all week and answered questions within an hour
• The feature flag let us switch off the new search for one customer instead of rolling back
• Agreeing on the API shape on Monday meant mobile and backend worked in parallel

What didn't go well: what got in the way

Everything that made the outcome harder or pushed it out of reach: delays, misunderstandings, technical problems, interruptions. The test: did it cost us time, quality or scope this sprint? Things that are merely irritating but had no effect on the outcome can wait for another format.

Ask for facts rather than verdicts. "Communication was bad" can't be acted on; "the scope change on Tuesday reached QA on Thursday" can.

• Two days lost while the staging environment was down
• The empty-state design arrived after the frontend was finished
• Three urgent support escalations, each pulling a different developer off sprint work
• The email templates took twice the estimate because nobody had touched that code in a year

Use this template — it's free

A 45-minute What Went Well agenda

Works for five to nine people; with more, give discussion an extra ten minutes.

1. Warm-up, 4 minutes. A light question from our icebreaker questions gets everyone talking before the real topics. ProstoRetro's built-in icebreaker gives each person a turn to answer, so nobody stays silent.
2. State the outcome, 3 minutes. What was the sprint goal, and did you reach it? One sentence the team agrees on. It frames everything that follows.
3. Check last retro's actions, 3 minutes. Open action items are shown at the start of the retro; close what's done and decide what to do with the rest.
4. Silent writing, 7 minutes. Both columns. Ask for at least two cards in each, so neither column is empty.
5. Read and group, 6 minutes. Cards from both columns about the same topic belong in one group: "pairing helped with the checkout bug" and "pairing slowed down reviews" are one conversation about pairing.
6. Vote, 3 minutes. Everyone votes for the topics they most want to talk about.
7. Discuss, 14 minutes. Pick the three topics with the most votes. For a topic that went well, ask "how do we make this happen again on purpose?"; for one that didn't, "what would have prevented it, and is that worth doing?"
8. Confirm actions, 3 minutes. Review the action items written during discussion. Each has one owner and a due date, and there are no more than three.
9. Close, 2 minutes. Ask each person for one thing they'll do differently next sprint.

For a 30-minute version, drop the warm-up, shorten writing to five minutes and discuss two topics. The structure holds up well under time pressure because there is so little of it.

Running it with a remote team

• Keep the outcome in view. On a call, a goal stated at the start is forgotten by minute ten. Paste it into the call chat or keep it on screen, and refer back to it when a card drifts.
• Keep the writing private. Two columns are easy to anchor: the first "didn't go well" card shapes the rest. ProstoRetro hides everyone's cards from the others until the grouping phase, so each person writes their own view of the sprint.
• Paste the facts onto the cards. A screenshot of the burndown, the error graph or the release timeline makes a card concrete. Cards can carry images straight from the clipboard.
• Check the mood when the outcome was missed. If the sprint failed, an anonymous pulse survey at the start shows how people feel about it, separately from the analysis. Its results are revealed during discussion.
• Get help with actions. With no action column, a discussion can end in agreement and no decision. ProstoRetro can suggest action items during discussion; treat them as a starting point to edit, not an answer.
• Invite the people who shaped the outcome. A designer, a support lead or a stakeholder can join from the link with just a name when the room is open to anyone.

Variations

Went well, Didn't go well, To improve

The most common extension adds a third column for improvement ideas. It makes the step from observation to action explicit, at the cost of a little more writing time. Build it in ProstoRetro as a custom template with your own column names, descriptions and colors, up to five columns. If you'd rather frame the third column as experiments, the built-in KPT does that with Keep, Problem and Try.

Single-event review

Use the two columns for one event instead of a sprint: a product launch, a database migration, a conference booth. Replace the sprint outcome with the event's goal and invite everyone who took part, including people from other teams. The plain wording works well with groups that don't usually do retros.

Went well only

After a long, draining stretch, run a short session — 20 minutes — where people write only in the first column. Ask for specifics: what helped, who helped, what you'd want to keep. A tired team gets more from this than from another list of problems, and the cards remind everyone what is worth defending once the deadlines are back.

Common mistakes

• No outcome, no anchor. Without a stated goal, "went well" becomes "I liked it" and the board turns into a satisfaction survey.
• One-word cards. "Communication", "estimates", "process". Ask the author for the example behind the word; that example is the real card.
• The negative column swallows the meeting. If "didn't go well" takes every vote, reserve one discussion slot for a topic that went well. Knowing why something worked is how you repeat it.
• Observations without actions. Two columns make it easy to finish with a shared understanding and nothing to do. Every discussed topic ends with an action or a decision not to act.
• The same card every sprint. If "staging is down" appears for the third time, stop discussing it in the retro. Make it a piece of work with an owner and a deadline.
• Never changing format. It is a great starting point, but answers get predictable after a few months. Rotate it with other templates.

FAQ

What questions does a What Went Well retrospective ask?

Two: what went well, meaning what helped the team achieve the sprint outcome, and what didn't go well, meaning what worked against it. Actions come out of the discussion of the top-voted topics.

How long does a What Went Well retrospective take?

Plan 45 minutes for five to nine people. With only two columns, it shrinks to 30 minutes without losing much.

What is the difference between What Went Well and Start Stop Continue?

What Went Well collects observations about what happened; Start Stop Continue collects proposals for what to do. Use What Went Well to understand a sprint, and Start Stop Continue once the facts are clear and the team is ready to choose changes.

Is What Went Well a good format for a first retrospective?

Yes. It needs no explanation, the questions are neutral, and the team can focus on learning the rhythm of a retro: writing, grouping, voting, discussing and agreeing on actions.

Can I run a What Went Well retrospective online for free?

Yes. Pick What Went Well when you create a board in ProstoRetro; it costs nothing, and nobody has to install anything. For a step-by-step tour, read how to conduct a great retro, or see all the retrospective templates.