20 Deep Questions to Ask in Your Next Sprint Retrospective
ScrumPoi · · 12 min read
“Our retros are fine.” No, they’re not.
If your team keeps having the same conversations every sprint (“We need better estimates”, “We should test earlier”), your retrospectives are broken.
Here’s the uncomfortable truth:
Most sprint retros are shallow status meetings pretending to be continuous improvement.
- People share safe, surface-level feedback
- The same 3 loud voices dominate
- Action items quietly die in Jira purgatory
- Nothing actually changes
Yet retros are the only Scrum event explicitly about improving how you work. If you’re not asking deeper questions, you’re just burning an hour every two weeks.
Let’s fix that.
Below are 20 deep questions that will turn your next sprint retrospective from “meh” into “useful”. I’ll group them by theme, explain when to use them, and give concrete examples so you’re not stuck staring at a blank board.
1. Questions That Expose Real Value (Not Just Output)
Most teams obsess over velocity, story points, and burndown charts. That’s output, not outcome.
1. “What did we ship this sprint that actually mattered to users?”
Don’t ask, “What did we complete?” Ask, “What made a difference?”
Use this when:
- Your team is hitting velocity targets but stakeholders still seem unhappy
- You’re shipping a lot of “stuff” but adoption is low
Follow-ups:
- How do we know it mattered? (metrics, feedback, support tickets)
- If nothing clearly mattered, why did we choose this work?
Example:
A team realized that 60% of their sprint was internal refactoring no one outside the team asked for. Valuable? Maybe. But they hadn’t communicated the value, nor balanced it with user-facing improvements. Next sprint, they explicitly reserved 40% of capacity for high-impact user requests.
2. “If we had to delete one thing we did this sprint, what would it be and why?”
This question forces trade-offs and surfaces hidden regret.
Use this when:
- The team feels busy but not effective
- You suspect gold-plating or over-engineering
Patterns to look for:
- Work that was done “just in case”
- Features built without validation
- Meetings that didn’t move anything forward
3. “What did we not do this sprint that we’ll regret in 3 months?”
Most retros look backward. This one looks forward.
Use this when:
- Tech debt is piling up
- Strategic work keeps getting bumped for “urgent” requests
Example outcomes:
- “We keep postponing test automation for the payments module.”
- “We didn’t talk to a single real user this sprint.”
Turn these into explicit backlog items with owners and due dates.
2. Questions That Reveal Systemic Bottlenecks
It’s rarely “Bob’s fault”. It’s almost always the system.
4. “Where did work spend most of its time waiting?”
Cycle time is usually dominated by waiting, not coding.
Use this when:
- Stories take multiple sprints to finish
- Work keeps getting “stuck in review” or “waiting for QA”
Ask the team:
- What column on our board has the longest queues?
- Where did we see the most context switching?
Example:
A team discovered that stories spent 3 days in “Ready for QA” on average, but only 4 hours actually being tested. That led them to cross-train devs on basic testing and pair on critical stories.
5. “What surprised us about the work this sprint?”
Surprises are signals of weak discovery or weak refinement.
Use this when:
- Estimates are consistently way off
- Scope keeps expanding mid-sprint
Dig deeper:
- What did we think this work was at planning time?
- What information did we miss?
- How can we surface this earlier next time?
6. “What did we have to rework, and why?”
Rework is pure waste if you don’t learn from it.
Use this when:
- Bugs keep reopening
- Requirements change mid-sprint
Look for:
- Misalignment with Product Owner
- Lack of acceptance criteria
- Skipped tests or reviews
Then decide: is this a one-off mistake or a repeatable pattern?
3. Questions That Surface Team Health (Without Therapy-Speak)
You don’t need to turn your retro into group therapy, but ignoring team health is how you end up with quiet quitting and surprise resignations.
7. “When did you feel most frustrated this sprint?”
Not “Were you frustrated?” (easy to dodge), but when. That anchors the feeling to specific events.
Use this when:
- You sense tension, but no one names it
- Slack messages are getting passive-aggressive
Follow-ups:
- What made that moment frustrating?
- What would have made it less painful?
Patterns to watch:
- Constant interruptions
- Conflicting priorities from different managers
- Unclear ownership
8. “What did we say ‘yes’ to that we should’ve said ‘no’ to?”
Overcommitment is usually self-inflicted.
Use this when:
- The team keeps “almost” finishing everything
- People complain about being overloaded
Examples:
- Sneaking in “just one more ticket” mid-sprint
- Accepting work with unclear requirements
- Saying yes to meetings that add no value
Turn this into a team policy:
- “We don’t accept work without clear acceptance criteria.”
- “We don’t add scope mid-sprint without dropping something else.”
9. “Where did you feel you couldn’t speak up?”
This one is uncomfortable—and that’s the point.
Use this when:
- You suspect psychological safety issues
- Retros feel too polite, too fast, too agreeable
You might hear:
- “I didn’t want to question that estimate.”
- “I didn’t feel safe pushing back on the deadline.”
- “I thought the design was wrong, but everyone seemed aligned.”
Your job as facilitator is to normalize dissent:
- Thank people explicitly for naming these moments
- Ask, “What would have made it easier to speak up?”
4. Questions That Challenge Your Process (Instead of Worshipping It)
Scrum is a tool, not a religion. Question it.
10. “If we had to cut one Scrum event next sprint, which would we cut and why?”
Use this to expose where ceremonies have become empty rituals.
You might learn:
- Planning is too detailed and drains energy
- Daily standups are status reports, not coordination
- Retro is rushed and treated as optional
Don’t actually cut it right away. First ask:
- What problem is this event supposed to solve?
- How could we redesign it to actually solve that problem?
11. “What did we do this sprint that was process theater?”
“Process theater” = things we do to look organized, not to create value.
Examples:
- Updating Jira fields no one reads
- Meticulous story point debates
- Writing docs that never get used
Ask:
- If we stopped doing this for two sprints, what would break?
- Who actually benefits from this activity?
12. “Where did we optimize for local efficiency but hurt the whole system?”
Classic anti-pattern: each function optimizing for itself.
Examples:
- QA refusing to test until everything is “dev complete”
- Devs batching work to avoid context switching, causing big handoffs
- Product pushing for more features at the cost of quality
Ask:
- Who felt the pain of that local optimization?
- How can we measure system-level flow instead?
5. Questions That Strengthen Collaboration and Ownership
Deep retros turn “my work” into “our product”.
13. “Who helped you the most this sprint, and how?”
Use this to:
- Make invisible collaboration visible
- Encourage more of the behavior you want
Instead of vague “great job everyone”, get specific:
- “Alex paired with me on the auth bug and unblocked me in an hour.”
- “Priya jumped into support calls so we could understand real user pain.”
This also reveals who is overloaded with helping and might need relief.
14. “What decisions did we delay that we should have made earlier?”
Indecision is a silent productivity killer.
Use this when:
- Stories linger in “In Progress”
- People say “I’m waiting on X” a lot
Ask:
- What decision were we waiting for?
- Who could have made it?
- How can we shorten that decision path next time?
15. “What did we do this sprint that future-us will thank us for?”
Not everything is about immediate value. This question validates good long-term bets.
Examples:
- Adding monitoring around flaky components
- Documenting a painful setup process
- Deleting a legacy module
This balances the previous “what should we delete” question and avoids demonizing all non-feature work.
6. Questions That Turn Learning Into Habit
Retros should create compounding learning, not just one-off tweaks.
16. “What experiment did we run this sprint, and what did we learn?”
If the answer is “none”, that’s the problem.
Use this to:
- Normalize experiments (WIP limits, pairing, new testing approaches)
- Focus on learning, not success/failure
Example:
- “We tried 15-minute timeboxed code reviews. Result: better focus, fewer nitpicks.”
- “We limited WIP to 2 per dev. Result: less multitasking, faster cycle time.”
17. “What will we measure next sprint to know if we improved?”
Vague action items are why retros feel useless.
Instead of “We’ll communicate better”, ask:
- What behavior will change?
- How will we know?
Examples:
- “Reduce average cycle time from 6 days to 4 days.”
- “Cut reopened bugs from 8 to 4.”
- “Have at least 2 stories with real user feedback before building.”
Tie your changes to observable metrics, even if they’re rough.
18. “What should we stop doing, even if it feels ‘productive’?”
Busy work often feels satisfying but creates no leverage.
Examples:
- Manually testing things that could be automated
- Writing lengthy design docs no one reads
- Over-refining low-priority backlog items
Ask:
- What’s the smallest safe experiment to stop this for one sprint?
19. “What’s one thing we’ll do differently starting tomorrow, not ‘next sprint’?”
“Next sprint” is abstract. “Tomorrow” is real.
Use this to:
- Force immediate, concrete changes
- Avoid the “we’ll do better next time” handwave
Examples:
- “Tomorrow, we’ll try having standup in front of the board and actually move cards.”
- “Tomorrow, we’ll start pairing on the riskiest story first.”
20. “If a new team joined us to learn ‘how to do agile’, what would we be proud to show them—and what would we hide?”
This exposes your real standards.
Ask:
- What are we genuinely good at?
- What are we quietly ashamed of?
The “hide” list is your improvement roadmap.
Common Mistakes in Retros (What Not to Do)
You can have great questions and still run terrible retros. Watch out for these traps:
Mistake 1: Turning retros into blame sessions
Symptoms:
- Names attached to every problem
- People defending themselves instead of exploring causes
Fix:
- Focus on systems, not individuals
- Use language like “Our process made it easy to…” instead of “You forgot to…”
Mistake 2: Collecting feedback and doing nothing with it
If action items don’t get done, people stop being honest. It’s that simple.
Fix:
- Limit yourself to 1–3 changes per sprint
- Assign a clear owner and due date
- Review last retro’s actions at the start of the next one
Mistake 3: Asking the same shallow questions every time
“Start / Stop / Continue” is fine… once in a while. Used every sprint, it becomes white noise.
Fix:
- Rotate question themes: value, flow, team health, process, learning
- Bring 3–5 focused questions, not a giant laundry list
Mistake 4: Letting the loudest voices dominate
If the same people always speak first, you’re not getting the team’s brainpower.
Fix:
- Start with silent writing on sticky notes or in a tool
- Use anonymous inputs for sensitive topics
- Only then move to group discussion
Mistake 5: Treating retros as optional or rushable
If you consistently cut retro time, you’re saying “Improvement is less important than output.”
Fix:
- Timebox realistically (60–90 minutes for a 2-week sprint)
- Protect the calendar like you would a production incident review
- Cancel other meetings before you cancel the retro
How to Run a Deeper Retro: Practical Steps
Here’s a concrete recipe you can try next sprint.
Step 1: Pick a theme and 4–6 questions
Examples:
- Theme: Flow & bottlenecks → Questions 4, 5, 6, 14
- Theme: Team health & safety → Questions 7, 8, 9, 13
- Theme: Value & outcomes → Questions 1, 2, 3, 15
Don’t try to use all 20 at once.
Step 2: Start with data, not opinions
Spend 5–10 minutes looking at:
- Cycle time, WIP, blockers
- Defects found, reopened bugs
- Deployed features and usage metrics (if you have them)
Then ask: “Given this, how do we feel about the sprint?”
Step 3: Use silent brainstorming first
For each question:
- Give everyone 3–5 minutes to write their answers silently (sticky notes or online board)
- Cluster similar notes
- Vote on which clusters to discuss
This avoids groupthink and anchors.
Step 4: Turn insights into one-page experiments
For the top 1–3 issues:
- What will we try?
- For how long? (usually 1–2 sprints)
- How will we measure if it helped?
- Who owns checking the result?
Write it down. Keep it visible.
Step 5: Close with a meta-question
Use one of:
- “Was this retro worth the time? Why or why not?”
- “What should we change about how we run retros next time?”
Retros themselves should evolve.
Tools Can Help, But They’re Not Magic
You don’t need fancy tooling to ask better questions—but the right tools can remove friction.
If you want quick, anonymous input and lightweight facilitation, tools like ScrumPoi help: it supports retros and planning poker, anonymous voting to avoid anchoring, and even Jira integration, all without forcing everyone to sign up first. Use tools like that to make the hard conversations easier to start.
Wrap-Up: Stop Doing “Retro Theater”
Most teams don’t need more ceremonies. They need braver questions and smaller, real changes.
Use these 20 questions as a menu:
- Pick a theme
- Ask fewer, deeper questions
- Turn insights into experiments
- Measure what changes
If your retro doesn’t occasionally feel uncomfortable, it’s probably not doing its job.
