Sprint Retrospective Questions: 60 That Get Honest Answers, Grouped by Situation

Good sprint retrospective questions are specific to what just happened. A missed goal, an outage and a new teammate's first sprint each need different questions, and a generic "what went well?" gets generic answers. Below are 60 retrospective questions in nine sets, each with when to use it and follow-up probes. Don't use all 60. Pick three to five: one about last retro's action items, two or three for this sprint's situation, and one to close.

How to pick your questions

📋

Questions 1–6

Every retro, first 5 minutes

Review last retro's action items. Any format.

🙂

Questions 7–15

Nothing dramatic happened

Fits What Went Well.

🎯

Questions 16–22

Missed sprint goal

Fits Sailboat.

🚨

Questions 23–29

After an incident or outage

Fits What Went Well, or Mad Sad Glad if people are rattled.

👋

Questions 30–36

New team or new joiner

Fits 4Ls.

🔄

Questions 37–42

After a reorg or process change

Fits 4Ls.

🔁

Questions 43–48

The same issue keeps coming back

Fits Start Stop Continue.

💬

Questions 49–55

Team health and safety

Fits Mad Sad Glad.

✅

Questions 56–60

Every retro, last 5 minutes

Turn the discussion into one or two commitments. Any format.

Why three to five, not ten? Every question you add takes time from the ones that matter. Esther Derby, in Eight Reasons Retrospectives Fail, advises choosing one or two actions per iteration. Ten questions leave you with ten half-discussed topics instead of two decisions.

1. 0–5 min

   Q1–Q3: last retro's action items

2. 5–15 min

   Q16: when did we first suspect we'd miss?

   Silent writing

3. 15–30 min

   Q18: which assumption was wrong?

4. 30–40 min

   Q19: what came in unplanned?

5. 40–45 min

   Q56: which one or two actions, and who owns each?

For the full agenda, see the sprint retrospective guide.

Opening questions: review last retro's action items

Use these at the start of every retro, for five minutes. Give each item from last time one of four statuses: done, in progress, blocked, or drop. Skipping this step is how teams end up agreeing on the same actions every sprint.

1. Which of last retro's action items are done, and did they change what we hoped they would?
2. What's still in progress, what's the next concrete step, and who owns it?
3. What's blocked, and who outside this team do we need to unblock it?
4. Which items should we drop on purpose, and what are we accepting by dropping them?
5. Which item did we agree to and never touched, and what got in the way?
6. Which of last retro's actions made something worse or cost more than we expected?

Dig deeper:

• When someone says "done", ask: "What would we see if it worked?" Done and useful aren't the same thing.
• If an item has been "in progress" for two retros, ask whether it's too big or whether nobody actually wants it. Then re-scope it or drop it.

In Retro Rabbit, the Action Items panel's Previous Retro tab lists what you agreed last time, and Old / Unresolved Items shows older open items. Mark finished items complete, delete the ones you agree to drop, and for a blocked item, create a new action for the unblocking step with its own owner.

More on this in retrospective action items that actually get done.

Questions for a normal sprint

Use these when nothing dramatic happened. Ordinary sprints risk shallow retros, so these ask for specific moments, not opinions.

7. What's one thing from this sprint you'd want us to repeat exactly?
8. Where did work wait the longest, and what was it waiting on?
9. What took longer than we expected, and when did we first notice?
10. Who helped you this sprint in a way the rest of the team might not have seen?
11. Which meeting, review or handoff could we have skipped without losing anything?
12. What did you learn this sprint that someone else on the team should know?
13. What surprised you about the work, the users or the codebase?
14. If you could change one thing about how we planned this sprint, what would it be?
15. What small annoyance have you stopped mentioning because it seems too minor?

Dig deeper:

• "Can you give a specific example? Which day was it?" Turns "code review is slow" into "Jun's PR sat for three days".
• "What would have had to be true for that to go better?" Moves the answer from a complaint to a condition you can change.

Questions after a missed sprint goal

Use these when the team missed the sprint goal or carried a big chunk of work over. Focus on signals and assumptions, not on who got it wrong. The Scrum Guide asks for exactly this in a retro:

Assumptions that led them astray are identified and their origins explored.

16. When did you first suspect we wouldn't hit the goal, and what did we do with that signal?
17. What did we know at planning that we didn't act on?
18. Which assumption turned out to be wrong?
19. What work came in during the sprint that wasn't planned, and who decided to take it on?
20. If you'd asked each of us on day three, how would we have described the sprint goal?
21. What did we finish that mattered most, even though the goal slipped?
22. If this sprint started again tomorrow, what would we cut or change on day one?

Dig deeper:

• When someone says "the estimate was wrong", ask what information would have made it right, and whether that information existed at planning.
• Ask "What made that decision reasonable at the time?" It gets past blame and toward what the team actually knew.

Questions after an incident or outage

Use these after a production incident, once the formal incident review is done or scheduled. Leave root-cause analysis to the review; the retro covers team-level follow-ups.

23. How did we find out something was wrong, and how long after it started?
24. What made the problem harder to diagnose than it should have been?
25. What went right during the response that we should keep doing?
26. Where were people unsure who was in charge or what to do next?
27. What would have caught this before it reached users?
28. How are the people who were on call doing, and what would make the next incident less draining?
29. Which follow-up is ours to own, as opposed to another team's?

Dig deeper:

• If an answer names a person, rephrase it as a gap in the system: "What would have helped Sam catch it sooner?"
• Ask "What did the dashboards show at that moment?" It separates what was knowable then from what's obvious now.

Questions for a new team or a new joiner

Use these for a new team's first retro, or for someone's first retro on an existing team. New people see what everyone else stopped noticing, but they rarely say so unprompted.

30. What about how we work surprised you, good or bad?
31. What did you have to figure out alone that should have been written down?
32. What's still unclear to you about how decisions get made here?
33. What did your last team do that you miss here?
34. What do we do that you'd quietly stop if it were up to you?
35. How do you prefer to get feedback: in writing, one to one, or in the room?
36. What should we agree on as a team before the next sprint starts?

Dig deeper:

• New joiners hedge with "it's probably just me." Answer with "If it isn't just you, what would we change?"
• Ask the longer-tenured people: "Which of these did you also run into when you joined?"

Questions after a reorg or process change

Use these when the team changed shape or process: merged teams, a new manager, a move from Scrum to Kanban, a new on-call rotation or a new tool.

37. What's better since the change, specifically?
38. What used to work that we lost in the change?
39. Where is it unclear who owns something now?
40. What are we still doing out of habit from the old setup?
41. What did we expect the change to fix, and has it?
42. What would you need to see in the next month to call this change a success?

Dig deeper:

• Separate "I don't like it" from "it doesn't work" by asking for the last time it caused a real problem.
• If the change came from outside the team, ask which part the team can still shape. That's where your action items live.

Questions for when the same issue keeps coming back

Use these when a topic has shown up in three or more retros. The Agile Alliance glossary warns that the same issues recurring without measurable improvement may mean the retro has become an empty ritual. Often the issue isn't fully the team's to fix.

28.9%

of retro actions needed changes outside the team's control

Source: Easy Agile, State of Team Alignment 2026 (a tool vendor's survey of 419 people)

43. How many retros has this come up in, and what did we try each time?
44. Why didn't the last action on this work?
45. Which part of this can we control, which part can we only influence, and which part do we have to accept?
46. Who outside this team needs to hear about it, and who will tell them?
47. What would it cost us to stop trying to fix this and live with it?
48. What's the smallest experiment we could run in one sprint to learn something new about it?

Dig deeper:

• Question 45 comes from Aino Vonge Corry's "In the Soup" antipattern. Sort the notes into the three groups before you discuss solutions.
• Ask "Why?" up to five times about the last failed action, not the original problem. The fix that didn't stick usually tells you more.

We wrote more about this pattern in the biggest problem agile teams have with retrospectives.

Team health and psychological safety questions

Use these every few sprints, or when retros feel quiet or overly polite. In Retrium's 2017 survey of 277 people (Retrium is a retro tool vendor), 44% named people not feeling comfortable speaking up as a top retro challenge, as reported by InfoQ.

49. From 1 to 5, how sustainable was your workload this sprint, and what drove the number?
50. When did you hold back an opinion this sprint, and what made it feel risky?
51. What would make it easier to say "I don't know" or "I got that wrong" on this team?
52. Whose work is invisible to the rest of the team?
53. What disagreement have we been avoiding?
54. Which part of your week felt like busywork?
55. What would make you more likely to raise a problem early?

Dig deeper:

• If the scores look fine but the room is quiet, ask: "What would someone who's struggling say about this?" It gives people distance from their own answer.
• Don't push on a low score in the meeting. Thank the person, change one thing, and ask again next sprint.

Closing questions

Use these in the last five minutes of every retro. Their job is to turn discussion into one or two commitments.

56. Which one or two action items will we actually do this sprint, and who owns each?
57. How will we know by the next retro whether it worked?
58. What didn't we discuss today that we should have?
59. From 1 to 5, how useful was this retro, and what would make it a 5?
60. What will you do differently tomorrow because of this conversation?

Dig deeper:

• If there are more than three action items, ask "If we could only do one, which?"
• For question 57, write the check date into the action text, for example "Priya reviews the flaky test count at the retro on the 14th."

How to word retrospective questions for async retros

Live, a vague question gets clarified on the spot. In an async retrospective, the written prompt is all people get. Rules that help:

• One question per prompt. "What went wrong and what should we change?" gets half-answers to both.
• Ask for a moment, not an opinion. "Describe one time this sprint you waited on something" beats "How was collaboration?"
• Build the probe into the prompt. Nobody is there to ask "why?", so add it: "...and what caused it?"
• Post an example answer first. People copy what they see. In Retro Rabbit, notes are visible as soon as they're added, so the first note sets the tone for everyone after it.
• Give a size and a deadline. "One or two notes by Thursday" gets more answers than "add your thoughts."
• Use two or three prompts, not five. Each one needs a written answer from every person.

Fine live, vague in writing

• "How did the sprint go?"
• "Any blockers?"
• "Thoughts on the incident?"

Answerable in writing

• "Name one moment this sprint you'd want to repeat, and why."
• "Where did your work wait longest this sprint? What was it waiting on?"
• "How did you first hear about Tuesday's outage, and how long after it started?"

To run it, rename a column (Topic) to a short version of your question, such as "Assumptions that were wrong". Column changes carry into future retros, so switch back afterward. People answer on the board, in the Team Room's Quick Notes box, or with /retro your note if you've connected Slack. With 20 written answers, drag related notes together and CarrotIQ (Pro AI and the trial) names each group.

Try it in Retro Rabbit

In Retro Rabbit, your team adds notes during the sprint on any of five formats, and action items carry into the next retro, so questions 1–6 always have a list to work from. Start a 14-day free trial, no card needed. Pricing is per team, not per user: see pricing.

Related

• The sprint retrospective guide
• Retrospective action items that actually get done
• How to run an async retrospective
• Retrospective icebreakers for remote teams
• What Went Well retrospective template
• Start Stop Continue retrospective template
• All retrospective templates