Sprint Retrospective Questions and Formats That Get Honest Answers

The best sprint retrospective questions are specific enough to answer with an example and open enough that the team sets the agenda: “What slowed you down that nobody else could see?” gets more than “How did the sprint go?”. Pick three or four questions, or one format that frames them, collect answers before anyone discusses them, and end with one or two changes that each have an owner. The question bank and six formats below are grouped by what you are trying to find out.

What a retrospective is for

The 2020 Scrum Guide↗ (opens in a new tab) gives the Sprint Retrospective one purpose: to plan ways to increase quality and effectiveness. The team inspects how the last Sprint went across individuals, interactions, processes, tools and its Definition of Done; discusses what went well, what problems it met and how they were or were not solved; and identifies the most helpful changes. The most impactful improvements are addressed as soon as possible and may be added to the next Sprint Backlog. It ends the Sprint and is timeboxed to three hours for a one-month Sprint, usually less for shorter ones.

The practice is older than Scrum’s wording of it. The last of the principles behind the Agile Manifesto↗ (opens in a new tab) says that at regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Everything below is a way of doing that without it turning into a ritual.

A shape that works for any format

Esther Derby and Diana Larsen’s Agile Retrospectives↗ (opens in a new tab) organises a retrospective into five phases: set the stage, gather data, generate insights, decide what to do, and close. The formats below mostly cover the middle two; the other phases are what stop a retro becoming a complaint session or a meeting with no outcome.

The GOV.UK Service Manual↗ (opens in a new tab) suggests allowing 60 to 90 minutes, having one person host and choose the questions, and picking broad questions that let the team set the agenda. Its basic version: each person writes answers to each question on sticky notes, the group discusses them, and the host agrees actions and gives each one to a person.

Six retrospective formats, and when to use each

Most formats have no single origin and circulate under several names, so treat the labels loosely. What matters is the question each one makes the team ask.

• Start, stop, continue. What should we start doing, stop doing, and keep doing? Quick and action-shaped. Good for a new team or a short retro; weak at finding causes.
• Went well, went badly, puzzles, thanks. The four topics the GOV.UK Service Manual lists. The “puzzles” column catches the things nobody understands, which are often the real problem.
• The 4Ls: liked, learned, lacked, longed for. Balances feelings and facts, and the “learned” column is good after a Sprint with a lot of new technology.
• Sailboat. Draw a boat heading for an island (the goal). Wind is what pushed you forward, anchors what held you back, rocks the risks ahead. Useful when the team has lost sight of the goal, or when risks are being ignored.
• Mad, sad, glad. Emotions first. Use it when morale is the issue, or after a hard Sprint where people need to say how it felt before they can talk about causes.
• Timeline. Draw the Sprint along a line and have everyone place events on it, marked as highs and lows. Slower, but the best format for finding out why something happened, because it reconstructs the order people remember differently.

Rotate formats every few Sprints. A team that has answered the same three columns ten times starts writing the answers it wrote last time.

A question bank, grouped by purpose

To open

• In one word, how was this Sprint for you?
• On a scale of 1 to 5, how confident are you that we reached the Sprint Goal? Why that number?
• What happened to the actions we agreed last time?

About delivery

• What did we finish that we are proud of?
• What did we start and not finish, and at what point did we know?
• What took far longer than we expected, and what did we not know when we planned it?
• Where did work wait for someone, and who was it waiting for?

About how we worked together

• When did you ask for help this Sprint, and how quickly did you get it?
• What slowed you down that nobody else could see?
• Was there a decision you disagreed with but did not say so?
• Who helped you this Sprint, and how?

About process, tools and quality

• Which of our meetings could have been a message, and which message should have been a conversation?
• Did anything reach Completed that was not really done? What was missing?
• Which bug that escaped this Sprint should our Definition of Done have caught?
• What did we do by hand three times that should be automated or written down?

To decide and close

• Of everything on the wall, which one change would make the next Sprint noticeably better?
• How will we know, at the next retro, whether it worked?
• Who will make sure it happens?
• What was this retro like? What should we change about it?

Keeping it safe to be honest

A retro where people say what they think they should say is worse than none, because it produces confident actions aimed at the wrong problem. Many facilitators open by reading Norm Kerth’s Prime Directive↗ (opens in a new tab): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

• Write before you talk. Silent writing for five minutes means the first confident voice does not set every answer after it.
• Discuss events and systems, not people. “The release waited two days for review” is a problem you can fix; “Sam was slow” is not.
• Think about who is in the room. The Agile Alliance glossary↗ (opens in a new tab) notes that the presence of a manager, for instance, may inhibit discussion. If a manager joins, agree why beforehand.
• Keep what is said in the room. Share the actions outside the team, not the discussion that led to them.
• Rotate the facilitator, and let the facilitator take part last. The same host every time becomes the owner of the retro, and the team becomes the audience.
• Act on what you hear. Nothing makes people stop speaking up faster than the same issue raised three times with no change.

Turning outcomes into tasks with an owner

The point of a retro is the change that follows it. The Agile Alliance glossary suggests one or two improvements per retrospective may well be enough; too many and none of them get done. For each one, write down:

• The problem, in a sentence, with the evidence from the retro.
• The experiment: what you will do differently, and for how long.
• The owner: one named person, who does not have to do all the work but makes sure it happens.
• The check: how the next retro will know whether it worked.

Then put it where the rest of the work is. An action that lives in the retro notes is forgotten by Wednesday; an action on the board is seen every day, and the next retro can open by looking it up. The GOV.UK guidance is to aim to get the actions done before the next retro.

Retrospectives without sprints

Teams that work in a continuous flow still need to stop and look. The Kanban Guide describes reviewing the workflow from time to time, but adds that there is no requirement to wait for a formal meeting to change it. Two patterns work: a fixed monthly retro on the calendar, and a retro triggered by an event, such as a release, an incident or a task that took three times longer than anyone expected. For a Kanban team, useful questions are about flow: which items aged the longest and why, where work queued, and whether anything should change about what counts as done. For an incident, use a dedicated review; AI agent incident response covers one.

Retrospectives on AI-agent work

When an AI assistant does part of the work, it belongs in the retro as a subject, not a participant. The questions shift from how people felt to what the assistant was given and what came back:

• Which tasks did the assistant finish that a person later had to reopen or redo? What was missing from the task when it started?
• Where did it follow an instruction literally and get the wrong result? Which instruction?
• What did we check before accepting its work, and what did we take on trust?
• What did we keep explaining to it, session after session, that should be written down once?
• What did it do that we did not expect, and did we find out from the record or by accident?

The actions from those questions are usually changes to instructions rather than to people: a clearer task template, a new line in the assistant’s standing rules, a check it must pass before a task counts as done. Verifying AI-generated work goes further into the last of those.

Running the retro from a fenbs board

fenbs has no sprints and no retrospective screen, so the retro itself happens wherever your team talks. The board supplies the evidence and holds the actions.

• History lists every change with who made it and when, including the ones an AI assistant made, marked as such. Scroll the period you are reviewing to gather data without relying on memory.
• Two board filters answer the AI questions directly: “Done by AI, to check” lists pre-approved tasks an assistant finished that no person has checked yet, and “Completed, not tested” lists finished work nobody has tested.
• File each action as a task, usually an enhancement, with the problem in the note and the experiment in the plan. Put the owner’s name in the note, and have them press “Follow this task” so they are emailed when it moves or someone comments.
• Give retro actions a category such as “Retro” so the next retro can filter to them in one step.
• What the team learned about working with its assistant goes into the board’s AI context, which every connected assistant reads before it starts. A process decision goes on the Decisions page, with the people who decided it.