The questions you ask in a retrospective set the tone for everything that follows. Ask loaded or vague questions and you get defensive, surface-level answers. Ask open, blame-free questions and you create the conditions for people to say what they actually think. A retro that generates real honesty is not the result of psychological safety alone. It is also the result of the facilitator choosing words carefully enough that nobody feels they are being put on trial.
The question you ask shapes the answer you get. Blame-free language gets honest responses.
What makes a good retrospective question
Good retro questions share a few common traits. They are open-ended, so they cannot be answered with yes or no. They are future-focused where possible, pointing towards improvement rather than assigning blame for the past. And they create a sense of psychological safety, which means the language does not single anyone out or imply that something has already gone wrong.
The facilitator's job is to hold space for honest answers, which means resisting the urge to defend, explain, or redirect when something uncomfortable comes up. Good questions only work if people believe the answers will be heard without consequence.
- Open-endedInvites a real answer rather than a yes or no. Gives people room to say what they actually think.
- Future-focusedPoints towards what could improve, not just what went wrong. Keeps energy constructive.
- Blame-freeAvoids language that singles people out. Focuses on systems and situations, not individuals.
The questions
What went well
- 1.What is something from this sprint or period that you are genuinely proud of?
- 2.Where did we work particularly well together as a team?
- 3.What decision did we make that turned out to be the right one?
- 4.Was there a moment where we handled something difficult well? What made that possible?
- 5.What process or habit served us well this time that we should make sure to keep?
- 6.Is there anyone on the team whose contribution you want to call out?
What could be better
- 7.What made this period harder than it needed to be?
- 8.If we could do this sprint again, what is the one thing we would change?
- 9.Were there any moments where we lost time or momentum? What caused that?
- 10.Was there anything that surprised us in a negative way, and could we have anticipated it?
- 11.Were there communication gaps, like information that did not get shared when it should have?
- 12.Is there a pattern we keep seeing that we have not addressed properly yet?
Team dynamics
- 13.Did everyone feel able to raise concerns or flag problems during this period?
- 14.Were there moments where we could have supported each other better?
- 15.Did we surface disagreements openly, or did tensions sit below the surface?
- 16.Did anyone feel stretched too thin while others had capacity? How do we balance that better?
- 17.Was there anything that made someone feel undervalued or unheard?
- 18.What would make this team a slightly better place to work over the next month?
Process & workflow
- 19.Were there any tools or processes that slowed us down rather than helping?
- 20.Where did our workflow break down, even briefly?
- 21.Were dependencies on other teams or systems managed well, or did they cause delays?
- 22.Did our planning at the start of the period match reality by the end?
- 23.Are there any recurring blockers we keep hitting that we have not solved for?
- 24.What is one process change that would make the next sprint noticeably smoother?
Actions & next steps
- 25.What is the single most important thing we should change before the next sprint?
- 26.Is there something we keep saying we will improve but never actually do? What would it take to fix it this time?
- 27.What should we stop doing entirely, even if it has become a habit?
- 28.Is there a small experiment we could run next sprint to test whether something would work better?
- 29.Who should own each of the actions we have agreed today, and when will we review them?
- 30.How will we know at the next retro whether we actually followed through on what we committed to?
Turning answers into actions
The most common failure mode of a retrospective is not a bad conversation. It is a good conversation that produces nothing. You agree on three things to change. Nobody writes them down in a way that sticks. Two weeks later you are back in the same patterns. The retro was a therapy session, not a driver of change.
Actions from a retro need an owner and a deadline, just like any other piece of work. If nobody is accountable, nothing changes. Keep the list short. Two or three concrete changes are better than ten aspirational ones. And at the start of the next retro, review what you committed to last time. That accountability loop is what separates a team that improves from one that just talks about improving. Tag action items with Key Themes so you can see whether certain types of problems-like communication or process gaps-keep appearing across retros.
Manager Toolkit's retrospectives feature lets you run the session collaboratively, collect responses across categories, and turn the outcomes into tracked actions. Previous retro notes are there when you need them, so you can check what you agreed and whether it actually happened.
Run your next retro now
Questions, voting, timers, and action tracking, all built in.