Went Well / To Improve / Action Items retrospective template

The default sprint retro: two honest columns and a short list of actions somebody owns.

Went Well / To Improve / Action Items is the most widely used retrospective format there is. The team lists what worked, what did not, and then converts the second column into a small set of changes with owners. It has no metaphor to explain, no learning curve, and it fits comfortably in an hour — which is why most teams start here and many never need anything else.

The format lives or dies on the third column. Two columns of observations make a pleasant meeting; the action items are what make it a retrospective. A team that leaves with five vague improvements has done worse than a team that leaves with two specific ones, each with a name and a date attached.

Timebox

45–60 minutes

Team size

3–12 people

Cadence

Every sprint

The Went Well / To Improve / Action Items board

Went well

What worked this sprint that we should protect or repeat?

  • The release went out Tuesday with no rollback
  • Pairing on the migration means two people understand it now
  • Standup stayed under ten minutes every day
  • Design handed over the Figma files before the sprint started
  • We pushed back on two mid-sprint requests instead of absorbing them
  • On-call was quiet — last sprint’s alert cleanup worked

To improve

What got in the way or cost us time? Name the problem and what it cost, not the fix yet.

  • Code review waited two days on average; two tickets slipped the sprint
  • Staging was broken for a day and a half and nobody owned fixing it
  • We heard about the scope change in the demo, not before it
  • Five tickets were in progress on Wednesday and none were done
  • The flaky checkout test was rerun eleven times
  • Release notes went out late because nobody owned them

Action items

What changes next sprint, who owns it, and when is it done?

  • Add a two-person review rota to the team channel — owner, Monday
  • Fix or quarantine the checkout test this sprint — owner named
  • Cap work in progress at two tickets per person, starting now
  • Ask for scope changes in writing before the sprint, not in the demo
  • Add release notes to the definition of done and update the checklist
  • Bring the staging outage back to the next retro with the fix in place

How to run a Went Well / To Improve / Action Items retrospective

  1. 1

    Set the stage and review last sprint’s actions (5 min)

    Restate the period under review, then read out the action items from the last retrospective and mark each one done, dropped, or still open. Teams that skip this step train everyone that action items are optional.

  2. 2

    Silent writing (8–10 min)

    Everyone fills Went well and To improve at the same time, with cards hidden. Writing in silence stops the first confident voice from setting the agenda, and it gets quieter team members onto the board.

  3. 3

    Reveal and group (5 min)

    Reveal every card at once and cluster duplicates into themes. Read the Went well column out loud first — under deadline pressure teams rush past it, and that is how good practices quietly get dropped.

  4. 4

    Vote on what to improve (3 min)

    Each person gets 3–5 votes to spend across the To improve themes. Blind voting, revealed at the end, keeps people from stacking votes on whatever the lead voted for.

  5. 5

    Discuss the top themes (15–20 min)

    Take the top 2–3 themes in order and give each a timebox. For each one, get to the cause before the fix: what actually happened, how often, and what it cost the sprint.

  6. 6

    Write the action items (5–8 min)

    Turn each discussed theme into at most one action item with a named owner and a date. Read the final list back to the team — if an item cannot be said in one sentence, it is a project, not an action item.

Went Well / To Improve examples for engineering teams

Went well

  • Feature flags let us ship the risky change on a normal day
  • CI stayed green all sprint after the dependency caching fix
  • The incident write-up took twenty minutes and answered every question
  • Two juniors shipped their first solo tickets

To improve

  • The build takes 22 minutes, so people batch pushes and reviews pile up
  • Two production issues both came from untested config changes
  • Tech-debt tickets lost prioritisation for the fourth sprint running
  • Only one person can deploy the reporting service

Action items

  • Split the test suite across two runners and measure the build time next sprint
  • Require a config diff review before merge — added to the PR template
  • Reserve 10% of capacity for debt and check at the next retro whether it held
  • Pair on every reporting-service deploy for two weeks

Examples for scrum teams and delivery managers

Went well

  • The sprint goal was one sentence and everyone could repeat it
  • Refinement happened two days before planning, so planning took 40 minutes
  • We demoed to actual stakeholders instead of to ourselves
  • Capacity planning accounted for support duty for the first time

To improve

  • Three tickets rolled over for the third sprint in a row
  • The definition of done means something different to each pair
  • Two people were pulled onto an escalation with no re-planning
  • Nobody looked at the retro board between sessions

Action items

  • Re-scope anything that rolls over twice instead of carrying it again
  • Put the definition of done on the board and check it in sprint review
  • Re-plan the sprint out loud whenever someone loses more than a day
  • Pin the action items in the team channel on the day of the retro

Examples for remote and async teams

The format is the easiest of all to run asynchronously, because the two prompts need no explanation. Collect cards over a day or two, then meet only for the discussion and the actions.

Went well

  • Written decision summaries meant the two people in other time zones stayed current
  • Recorded demos got more feedback than the live ones used to
  • Overlap hours stayed protected for decisions, not status
  • Every ticket had a written handover note

To improve

  • Decisions made in calls never reached the people who were asleep
  • The retro board is filled by the same four people every time
  • Time-zone maths added a day to every review cycle
  • Onboarding docs were two releases out of date

Action items

  • Post a written decision summary within an hour of every call
  • Collect cards async over two days before the live session
  • Set a one-business-day review SLA measured in the reviewer’s hours
  • Add a docs check to the release checklist — owner rotates with on-call

Best for

  • Sprint retros where the team wants structure without a new format to learn
  • First retrospectives, new teams, and stand-in facilitators
  • Teams that rotate facilitators and need something anyone can run
  • Any session where the priority is leaving with decisions, not insight

Facilitation tips

Spend real time on Went well

The instinct is to treat it as a warm-up and get to the problems. Resist it: the Went well column is where the team learns which of its own practices are worth defending when the next deadline arrives.

Two or three action items, never eight

Action items compete with delivery work. Three is the most a team can genuinely absorb in a sprint, and a short list that gets done builds more trust in retros than a long list that does not.

Put the cost in the To improve card

"Reviews are slow" gets sympathetic nodding. "Reviews took two days and two tickets missed the sprint" gets a decision. Ask what each problem cost in time, rework, or missed commitments.

Every action item has one name on it

Not a team, not a role — a person, and a date. Shared ownership of a process change reliably means nobody starts it, and the item reappears on the board next sprint word for word.

Variations

Two columns only

Drop the third column and write action items directly onto the discussed cards. Faster for teams already disciplined about follow-through, and the usual shape when the format is called simply "what went well / what didn’t go well".

Plus / Delta

The same two prompts with neutral labels: plus for what worked, delta for what should change. Useful when "to improve" has drifted into a complaints column, because delta reads as a change rather than a verdict.

Add a kudos column

A fourth column for appreciation of specific people. It takes two minutes, it does not compete with the improvement discussion, and it gives the team a reason to name each other’s work out loud.

Async collection, live decisions

Open the board two days early, let people add and group cards on their own time, and use the live session only to vote, discuss the top themes, and agree owners. Cuts the meeting to 25 minutes.

Frequently asked questions

What is the Went Well / To Improve / Action Items retrospective?+

It is the standard three-column sprint retrospective: the team lists what went well, what should be improved, and then agrees on the specific action items that come out of the discussion. It is the most common retrospective format because it needs no explanation and produces decisions directly.

What do you write in the "went well" column?+

Anything that worked and is worth repeating: practices, decisions, tools, or moments where the team handled something well. Be concrete — "the release went out Tuesday with no rollback" tells the team what to protect, while "good sprint" does not.

Is this the same as "what went well, what didn’t go well"?+

Yes — it is the same format under a different name, and the two-column version usually leaves action items implicit. Adding the explicit third column is what stops the meeting from ending in agreement that nothing then changes.

How many action items should a retrospective produce?+

Two or three, each with one named owner and a date. Action items run alongside normal delivery work, so a longer list means none of them get real attention — and the next retrospective opens with a row of unfinished items.

How is it different from Start, Stop, Continue?+

Start, Stop, Continue asks for behavior changes directly, so every card is already a proposed action. Went Well / To Improve separates observation from decision: the team gathers evidence first, votes on what matters, and only then writes actions. It suits teams that want to discuss causes before jumping to fixes.

How long does it take?+

Plan 45–60 minutes for a two-week sprint with up to eight people: 5 minutes reviewing last time’s actions, 10 writing, 5 grouping, 3 voting, 20 discussing, and 8 writing action items. A one-week sprint runs comfortably in 30 minutes with the same structure.

Run Went Well / To Improve / Action Items online in FocusRetro

The Went Well / To Improve / Action Items template is built in: pick it when creating a board, invite the team with a link, and run the phases with timers and blind voting. Free plan available at focusretro.com.

Open the template free

No credit card required

Related guides

Start, Stop, Continue retrospective template

The fastest way to turn team feedback into concrete behavior changes.

Plus, Minus, Interesting retrospective template

The three-column sort with a home for the observations every other format throws away.

Mad, Sad, Glad retrospective template

An emotions-first retro that surfaces how the sprint felt before anyone proposes a fix.

4Ls retrospective template: Liked, Learned, Lacked, Longed For

Four lenses that separate what the team felt, learned, missed, and wished for.

How to run a sprint retrospective (step-by-step guide)

A step-by-step sprint retrospective guide: the 5-phase agenda, exact timings for a 60-minute session, facilitation tactics, remote tips, and common failure modes.

What is a retrospective? The complete guide for teams

A retrospective is a recurring team meeting for inspecting how you work and deciding what to change. Learn the formats, agenda, timings, and mistakes to avoid.

Retrospective timebox calculator

How long Went Well / To Improve / Action Items should run for your sprint length and team size, split across the five phases.

Icebreaker and check-in questions

Openers for the first two minutes of a Went Well / To Improve / Action Items session, sorted by situation.