Sprint Retrospective Agenda: 5 Formats That Produce Action Items

A sprint retrospective meeting agenda is a timed plan for the meeting where the team looks at how it worked and leaves with a few improvements it will actually make. The agendas that work are short, name a facilitator, and end with owners and dates. Below are five formats, a 45-minute skeleton, and a worked example you can copy.

A sprint retrospective meeting agenda in 45 minutes

Forty-five minutes is enough for a two-week sprint with a team of about five to nine people. Sixty minutes fits a longer or tense sprint. If you need ninety, the group is usually still gathering opinions when it should be choosing.

Put the sprint retrospective meeting agenda in the calendar invite so people arrive knowing the format. A sample block:

Minutes	Block	Output
0-5	Open: sprint goal, one rule, the format	Everyone knows what "done" means for this meeting
5-15	Gather: silent notes on the format's prompts	A board of observations instead of a monologue
15-30	Group and vote: cluster, then dot-vote	Two or three themes, ranked
30-42	Decide: one action per chosen theme	Owner, first step, check date
42-45	Close: read the actions back	No silent disagreements left in the room

The Scrum Guide describes the Sprint Retrospective as the event where the team inspects itself and plans ways to raise quality and effectiveness. It doesn't prescribe a worksheet, so you choose the format. What it does require is that the result changes how you work.

What the meeting is for

A sprint retrospective looks backward only long enough to choose a change. It is not the sprint review, which inspects the increment with stakeholders. The retrospective looks at tools, collaboration, decisions, interruptions, and the sprint goal.

If nobody can repeat the last sprint's goal, fix that in planning. A longer retro won't solve it. A clear sprint goal gives you something concrete to inspect: did the way we worked make that goal more or less likely?

Keep a retro agenda to one page. When the script is longer than the meeting, the hour goes to managing the exercise.

Five formats that produce actions

Pick one format per meeting and stay with it for three or four sprints. Switch when the notes start repeating. If you rotate every week, people never learn the prompts.

Start, stop, continue

Three columns: start doing, stop doing, continue doing. People write silently, then you cluster.

This suits a team that already ships and needs to adjust how it operates. Don't skip "continue." Teams that only hunt for problems end up dropping the habits that work.

"Communicate better" is not an action. "Stop starting a second feature before the first is in review" is. Push on every note until it names a behavior.

Mad, sad, glad

Three columns: what made people mad, sad, or glad. Use it when the sprint was emotionally loud and a process board would skip the real issue. A production incident, a broken promise to a customer, or a decision made in a side channel often shows up here first.

Treat the board as input. After grouping, ask which items you can change next sprint and which you only need to acknowledge. Acknowledging something is fine. If you pretend every feeling has a process fix, the next retro turns cynical.

Written notes work as well as a round-robin, and you can read them aloud without names if the team prefers.

Sailboat

Draw a boat, an island (the goal), wind (what helped), an anchor (what dragged), and rocks (risks ahead). Guests can join without a lecture, and shy people get a place to put a note.

It works badly when the same anchor has already come up three times. At that point you need a decision, not another drawing. Make the island next sprint's goal rather than "go faster," so the wind and anchor attach to a real target.

Four Ls

Liked, learned, lacked, longed for. The four columns force a split between facts and wishes.

• Liked: what you would repeat on purpose.
• Learned: a lesson that should change a checklist, a test, or a default.
• Lacked: a missing input, person, or tool that blocked finished work.
• Longed for: a wish. Park these unless someone will own a first step.

Wish lists hide in "longed for." Read them, then move anything without an owner to a parking lot the team can see but doesn't have to service. If the parking lot turns into a second backlog, it will rot.

One experiment

Skip the wide board. Each person proposes one change small enough to try for a single sprint, with a way to tell whether it helped. The group picks one, sometimes two.

Use this when earlier retros produced five actions and finished none. The limit is what makes it work.

Write it as a hypothesis: "If we limit work in progress to two tickets per person, bug cycle time will drop, and we will check the board next retro." You need a before and an after the team can see.

Worked example: a six-person team on a Friday

This is an illustration, not a case study. A six-person product team finishes a two-week sprint. The goal was "merchants can issue a refund without asking support." They shipped it on Thursday after a Wednesday night fix. That afternoon the facilitator sends the sprint retrospective meeting agenda: Sailboat, 45 minutes, notes in a shared doc.

0-5. She restates the goal and one rule: notes first, no speeches yet. She writes the island as the goal they just finished, plus the draft goal for next sprint, which planning has not locked.

5-15. Silent writing. Wind: "the refund path had one owner." Anchor: "review sat for a day because two people were in sales calls." Rocks: "the same edge case is still untested."

15-30. They cluster and dot-vote. Review wait wins, and the untested edge case comes second. "More pairing" gets one vote and is parked.

30-42. Two actions:

1. Next sprint, the reviewer is named on the ticket before coding starts. Owner: the person who picks up the ticket. Check: Wednesday standup. First step: add the field to the ticket template today.
2. The edge case becomes a failing test before more refund work. Owner: the engineer who made the Wednesday fix. Check: Monday end of day.

42-45. She reads both actions back. Someone corrects the check date on the test, and they stop.

Nobody left with "communicate more." The next sprint planning meeting can reserve capacity for the test instead of discovering it mid-sprint.

How to turn notes into commitments

An action item has four parts: the change, the owner, the first step, and the date you will look again. "We should" fails all four.

Limit the retro to one to three actions. Add a fifth and the first three tend to die. If a theme matters and doesn't fit, write it where planning will see it and let planning accept or drop it. It's the same discipline as keeping a sprint backlog small enough to finish.

Open the next retro by reading last time's list and marking each item done, still open, or dropped. Dropping an item is fine if the team says so out loud. Silent carryover is how retros become theater.

A reviewed rollover is better than a fresh blank page. Falrow's cycles keep unfinished work visible across cycles with a reviewed handoff, so nothing rolls forward by accident. A shared doc with a "last retro" section does the same job if everyone opens it.

Where estimates and flow data help

Retros that run on memory alone go wrong, because the loudest incident becomes the whole story. Bring one or two facts: how many tickets finished, how many rolled over, and where work waited (review, clarification, or a dependency). If you estimate, check whether the large items were the ones that slipped. A full planning poker session does not belong in the retro.

Falrow's insights show cycle time percentiles, cumulative flow, and a Monte Carlo forecast built from the tickets themselves. In a retro, use that as a prompt ("half our bugs waited three days in review"), not as a scoreboard for individuals. Jira, Linear, or a spreadsheet can support the same conversation. Where teams go wrong is starting from a chart nobody agreed to look at, or from no record at all.

Who is in the room

Invite the people who did the work, including whoever set priority if they were part of the sprint's decisions. Stakeholders who weren't in the work belong at the review, because their presence changes what people will write down.

Rotate the facilitator. Someone who always runs it starts defending the process they designed. A rotating facilitator needs the agenda in the invite, a timer, and permission to cut off a speech that repeats a note already on the board. They stay quiet while people gather notes, refuse any action without an owner while the team decides, and at the close read the list and stop on time.

What happens before the next sprint

Actions that need time have to show up in planning. If "write the failing test" is real, it takes capacity. Agreeing to it in the retro and then filling the sprint with feature work cancels the retro.

Treat planning and the retrospective as a pair. The sprint planning guide covers how a team commits to a goal and a backlog it can finish. The retro's output is one input to that commitment, alongside support load, holidays, and work already in progress.

At the next retro, read the actions before you pick a new format. If both are done, the format worked. If neither was touched, shrink the agenda until the team leaves with one experiment it completes.

FAQ

How long should a sprint retrospective be?

Forty-five to sixty minutes fits most two-week sprints. Stay near the shorter end when the rhythm is steady and use the longer end after an incident or a missed goal. A monthly sprint can justify 90 minutes. Extra time rarely helps if the last meeting failed to name an owner.

What should every retro agenda include?

A retro agenda needs a named format, silent time to write, a way to choose (dot-vote or a hard limit), and a close that assigns owners and dates. It also needs five minutes at the start to read the last meeting's actions. Icebreakers and theme videos are optional, and if you're running behind, cut them before you cut the decision block.

How is a retrospective different from a sprint review?

The review looks at the product increment with the people who will use it or pay for it. The retrospective looks at how the team worked and decides what to change next sprint. When you mix them, stakeholders sit through process talk, or the team skips that talk because guests are present. Hold them as two meetings, even on the same day.

How many action items should we leave with?

One to three. Each one needs an owner, a first step small enough to start within a day or two, and a date to check. If you can't name those, you don't have an action yet. Park the rest where planning can see it, and review the list next time so that leaving work unfinished is a deliberate choice.