Retrospective Survey Questions: A Ready-to-Use Question Bank
Discover effective retrospective survey questions to gather honest team feedback. Enhance your retrospectives by implementing actionable changes.
Use these retrospective survey questions to surface honest feedback and turn it into one high-value improvement per cycle. The most effective approach combines a short pre-retro survey of 3–5 focused questions, sent 1–3 days before the session, with a single committed experiment as output. The Scrum Guide frames the retrospective around three core questions: what went well, what could improve, and what one improvement the team commits to next. Sprad's scoring thresholds give you a practical trigger system on top of that structure.
Start here:
- Pick a category from the question bank below (check-in, what went well, what didn't, wellbeing, action-oriented) based on what your team needs most right now.
- Choose 3–5 questions and paste them into your survey tool before the next retro.
- Decide on anonymity and timing upfront: anonymous forms sent 48–72 hours before the session consistently produce more candid responses than in-session polls.
Key Takeaways
A short pre-retro survey of 3–5 focused questions, scored against clear thresholds and closed with one owned experiment, is the most reliable way to turn a retrospective into a measurable improvement.
| Point | Details |
|---|---|
| Pick 3–5 questions per session | Rotating from a categorized bank prevents fatigue and keeps responses honest. |
| Send 48–72 hours before the retro | Reflection time produces more candid, useful responses than in-session polls. |
| Score against clear thresholds | Average < 3.0 on a 1–5 scale signals a critical issue requiring immediate action. |
| Close with one owned experiment | Name an owner and a success metric before the retro ends, then add it to the Sprint Backlog. |
| SwarmStack centralizes the workflow | One platform handles survey distribution, action capture, and follow-through tracking with export to Jira or GitHub. |
Table of Contents
- What makes a good retrospective survey question?
- The complete retrospective question bank, organized by goal
- When to run a retrospective survey and how to format it
- From survey responses to concrete improvements
- Three copy-paste survey templates
- Why pre-retro surveys work: evidence and Scrum alignment
- Common pitfalls in retrospective survey design and how to avoid them
- A facilitator's perspective on what actually changes teams
- SwarmStack makes survey-informed retrospectives easier to run
- Sources
What makes a good retrospective survey question?
The best retrospective survey questions do one thing: open a conversation rather than close it. That means one topic per question, neutral wording, and a format matched to what you actually want to learn.
Open vs. closed questions. Closed questions (Likert scales, 0–10 ratings) give you comparable data across sprints. Open questions give you the "why" behind a score. You need both. A survey that is all open text exhausts respondents; one that is all scales tells you that something is wrong but not what to do about it.
Scale choice matters more than most facilitators realize. A 1–5 Likert scale works well for agreement statements ("Our team communicated clearly this sprint"). A 0–10 scale works better for overall satisfaction or confidence ratings, where finer granularity catches meaningful differences. Avoid mixing scales in the same survey without labeling them clearly — respondents will anchor to the first scale they see.
Bias and length. Keep each question to one idea. "Did we communicate well and meet our goals?" is two questions disguised as one. Loaded wording ("Why did the sprint go so badly?") primes negative responses. Aim for 6–8 items maximum in a sprint survey; response rates drop sharply beyond that.
Good vs. bad phrasing — two examples:
Bad: "Don't you think our processes need improvement?" Good: "How satisfied are you with our current processes? (1 = very dissatisfied, 5 = very satisfied)" Why it matters: The first version leads the witness. The second gives you a number you can track.
Bad: "Did the sprint go well and did you feel supported?" Good: "How supported did you feel by your teammates this sprint? (1–5)" Why it matters: Splitting the question lets you act on each dimension separately.
Pro Tip: If anonymity is important, apply the Chatham House Rule to your retro: responses are shared freely, but no individual is identified. State this rule explicitly in the survey intro. Teams that know their candor is protected consistently give more useful feedback.
The complete retrospective question bank, organized by goal
Rotating your questions across cycles prevents retro fatigue and keeps responses fresh. Pick 3–5 per session, not the whole list.
Check-in and icebreakers
Use these at the top of a survey or live session to warm up participation.
- On a scale of 1–5, how are you showing up today? (1 = running on empty, 5 = fully charged)
- If this sprint were a weather forecast, what would it be?
- In one word, describe how you feel about the work we did this sprint.
- Rate your energy level entering this retro: 1 (low) to 5 (high).
- What is one thing you are looking forward to in the next sprint?
What went well
- Which part of this sprint are you most proud of? (open text)
- Rate how well the team collaborated this sprint: 1–5.
- What process or practice helped us deliver effectively? (open text)
- Our team communicated clearly this sprint. (1 = strongly disagree, 5 = strongly agree)
- Which team behavior should we keep doing? (open text)
- Rate the quality of our sprint planning: 1–5.
- We met our sprint goal. (1 = strongly disagree, 5 = strongly agree)
What didn't go well
- What was the biggest obstacle you faced this sprint? (open text)
- Rate how effectively we resolved blockers: 1–5.
- Which process slowed us down the most? (open text)
- We had the information we needed to do our work. (1 = strongly disagree, 5 = strongly agree)
- What one thing, if removed, would have made this sprint significantly better? (open text)
- Rate the clarity of requirements or acceptance criteria: 1–5.
Learning and insights
- What is one thing you learned this sprint that you want to apply next time? (open text)
- Rate how much you grew professionally this sprint: 1–5.
- What surprised you most about how the sprint unfolded? (open text)
- We reflected on our mistakes and learned from them. (1 = strongly disagree, 5 = strongly agree)
- What knowledge or skill gap became visible this sprint? (open text)
Action-oriented and commitment questions
- What is the single most important change we should make next sprint? (open text)
- Rate your confidence that we will follow through on our retro actions: 1–5.
- Which retro action from last sprint did we actually complete? (open text)
- We have a clear owner for each improvement we commit to. (1 = strongly disagree, 5 = strongly agree)
- What experiment would you most like to try next sprint? (open text)
Team wellbeing and psychological safety
- Rate your overall workload this sprint: 1 (unsustainable) to 5 (comfortable).
- I feel safe raising concerns or disagreements with the team. (1 = strongly disagree, 5 = strongly agree)
- Rate your stress level this sprint: 1 (very high) to 5 (very low).
- I feel valued for my contributions. (1 = strongly disagree, 5 = strongly agree)
- What would make the team a better place to work? (open text)
Stakeholders and customer alignment
- Rate how well we understood customer or stakeholder needs this sprint: 1–5.
- Our work this sprint moved us closer to the product goal. (1 = strongly disagree, 5 = strongly agree)
- What feedback from stakeholders should shape our next sprint? (open text)
Process and tools
- Rate the effectiveness of our current toolset: 1–5.
- Which tool or process created the most friction this sprint? (open text)
- Our meetings were a good use of time. (1 = strongly disagree, 5 = strongly agree)
- Rate how well our Definition of Done served us: 1–5.
Overall rating
- Overall, how would you rate this sprint? (0 = worst possible, 10 = best possible)
Scoring thresholds and action triggers
| Score range | Scale | Status | Recommended action |
|---|---|---|---|
| ≥ 4.0 | 1–5 Likert | Strong | Celebrate; keep consistent questions to track trend |
| 3.0–3.9 | 1–5 Likert | Needs improvement | Surface in retro; pick one experiment |
| < 3.0 | 1–5 Likert | Critical | Prioritize immediately; assign owner before retro ends |
| ≥ 7 | 0–10 overall | Healthy | Monitor; rotate questions next cycle |
| < 7 | 0–10 overall | Risk | Dig into open-text responses for root cause |
These thresholds come from Sprad's retrospective template, which pairs Likert items with a 0–10 overall rating to give teams a fast, comparable signal each sprint.
When a theme emerges from your scores, techniques like the speedboat retrospective can deepen the conversation by making anchors (blockers) and wind (enablers) visible to the whole team.
When to run a retrospective survey and how to format it
Timing and format determine whether you get honest data or performative answers. Here is a repeatable workflow built around TeamRetro's phase structure and Sprad's timing guidance.
- Send the survey 48–72 hours before the retro. This gives quieter team members time to reflect rather than react. Responses collected in the moment of a live session tend to cluster around the loudest voices.
- Brief participants in one sentence. Tell them the survey is anonymous (if it is), how long it takes (aim for under five minutes), and what you will do with the results. Vague surveys get vague answers.
- Close the survey 12–24 hours before the session. You need time to review scores, identify themes, and decide which questions to bring into the live retro.
- Open the live retro with aggregated results, not raw data. Show the average scores and the top two or three open-text themes. Do not read every response aloud.
- Use the gathered data to choose your live retro questions. Great facilitators let early survey data shape which insight and action questions matter most for that specific sprint, rather than running a fixed script.
- Close with one committed improvement. Write it on the board with an owner and a measurement window before anyone leaves.
Timing by team type:
- Scrum teams: before every sprint retro, without exception.
- Project teams: at each milestone and at project close.
- Stable operational teams: quarterly pulse surveys work well when the cadence of change is slower.
Distribution options:
- Anonymous form (Google Forms, Typeform, Microsoft Forms): highest candor, lowest traceability. Best for sensitive topics.
- In-tool poll (Miro, Confluence, Jira): convenient, but respondents may feel less anonymous even when the tool claims otherwise.
- Shared document: fast to set up, but almost never truly anonymous. Reserve for high-trust teams.
A note on response rates: if fewer than 70% of the team responds, your averages are unreliable. Non-response is rarely random — the people who skip surveys are often the ones with the strongest (usually negative) opinions. Chase non-respondents once, then note the gap when presenting results.
From survey responses to concrete improvements
Scores and open-text responses are only useful if they drive a decision. Convert them into 1–3 experiments, each with an assigned owner and a measurable success criterion, and you have a retro that actually changes something.
The workflow:
- Clean and summarize. Calculate average scores per category. Pull the three most common themes from open-text responses.
- Surface the top themes. Present the two or three items with the lowest scores or highest mention frequency. Resist the urge to show everything.
- Vote and prioritize. Give each team member two or three votes (dot voting works well). The item with the most votes becomes the sprint experiment.
- Convert to a SMART experiment. "We will improve communication" is not an experiment. "We will add a 10-minute async standup update in Slack every Tuesday and Thursday, and measure whether our communication score rises above 3.5 by next retro" is.
- Add to the next sprint or plan. The Scrum Guide's expectation is that visible improvements appear in the Sprint Backlog. Put the experiment there, with an owner.
Example action-item format:
| Field | Example |
|---|---|
| Experiment | Add async standup update twice per week |
| Owner | Priya (Scrum Master) |
| Success metric | Communication score ≥ 3.5 on next retro survey |
| Measurement window | End of next sprint |
Advanced teams can use a maturity scoring approach, where survey results are aggregated into a score across behaviors and practices, to benchmark progress across quarters. The Stephens Insight Group's Sprint Retro Survey is one example of this output format.
Pro Tip: Pair a quantitative threshold (average < 3.0 = critical) with the open-text short-list before deciding what to act on. A single outlier response can drag an average below 3.0 without representing a real team-wide problem. The open text tells you whether the score reflects a pattern or a bad week for one person.
Three copy-paste survey templates
Template comparison
| Template | Items | Completion time | Best used for |
|---|---|---|---|
| Sprint retro survey | 7 items | 3–4 minutes | Every sprint, sent 48–72 hours before retro |
| Project post-mortem | 14 items | 8–10 minutes | End of project or major milestone |
| Wellbeing pulse | 5 items | 2 minutes | Monthly or when workload signals appear |
Sprint retro survey (7 items)
Send 48–72 hours before the retro. Scale definitions: 1 = strongly disagree / very low, 5 = strongly agree / very high.
- We met our sprint goal. (1–5)
- Our team communicated clearly this sprint. (1–5)
- I had the information I needed to do my work. (1–5)
- Our processes and tools supported our work effectively. (1–5)
- I felt psychologically safe raising concerns. (1–5)
- What is the one thing we should change next sprint? (open text)
- Overall, how would you rate this sprint? (0–10)
Project post-mortem survey (14 items)
Send within 24 hours of project close. Scale: 1–5 unless noted.
- The project goals were clear from the start. (1–5)
- We delivered what the customer or stakeholder needed. (1–5)
- Our planning process set us up for success. (1–5)
- We managed risks and blockers effectively. (1–5)
- Team communication was clear and timely. (1–5)
- Roles and responsibilities were well defined. (1–5)
- We had the right tools and resources. (1–5)
- The project timeline was realistic. (1–5)
- Stakeholder feedback was incorporated effectively. (1–5)
- We learned from mistakes and adapted. (1–5)
- What went better than expected? (open text)
- What would you do differently if starting over? (open text)
- What process improvement should carry into the next project? (open text)
- Overall project satisfaction: 0–10.
Team wellbeing pulse (5 items)
Send monthly or when workload or morale signals appear. Scale: 1–5.
- My workload this period was manageable. (1–5)
- I feel supported by my team and manager. (1–5)
- I feel valued for my contributions. (1–5)
- My stress level is sustainable. (1–5)
- What would most improve your experience on this team right now? (open text)
Why pre-retro surveys work: evidence and Scrum alignment
The case for survey-backed retrospectives is not just practical — it is grounded in the Agile framework itself.
That is the Scrum Guide's framing, reinforced by Scrum.org's guidance on conducting a sprint retrospective: the output should be visible improvements added to the Sprint Backlog, not a conversation that evaporates when the meeting ends. A pre-retro survey creates a paper trail that connects the conversation to a committed action.
The Agile Manifesto's principles reinforce this further: the emphasis on individuals and interactions over processes and tools means that psychological safety questions belong in every retro survey, not just the occasional team health check.
Sprad's operational benchmark adds a practical layer: send the survey 1–3 days before the retro, score results against the thresholds in the question bank above, and use any category averaging below 3.0 as an automatic trigger for a focused conversation. Teams that follow this cadence consistently leave retros with one owned experiment rather than a list of vague intentions.
Common pitfalls in retrospective survey design and how to avoid them
Asking too many questions. A 20-item survey feels like a performance review. Response rates drop, and the answers you do get are rushed. Cap sprint surveys at 6–8 items; save longer formats for project post-mortems.
Using the same questions every sprint without tracking trends. Rotating questions keeps sessions fresh, but rotating everything means you can never compare scores across cycles. Keep 2–3 anchor questions constant (overall rating, psychological safety, communication) and rotate the rest.
Skipping the open-text question. Scores tell you where to look; open text tells you what you are actually looking at. One open-text prompt per survey is the minimum. Two is better for longer surveys.
Treating anonymity as optional. Teams that know their responses are traceable self-censor on the questions that matter most: workload, safety, and manager behavior. If your tool cannot guarantee anonymity, say so explicitly and adjust your expectations for candor.
Collecting data and doing nothing with it. This is the fastest way to kill survey participation permanently. If the team fills out a survey and sees no change discussed at the retro, they stop filling out surveys. Close the loop every single time, even if the answer is "we looked at this and decided not to act on it yet, here is why."
Phrasing questions that lead the respondent. "How much did poor planning hurt this sprint?" assumes poor planning happened. Neutral phrasing ("How effective was our sprint planning?") gets you a real answer. For risk-related retro questions, this matters especially: leading questions about blockers produce confirmation rather than discovery.
Ignoring non-response. If three out of eight team members skip the survey, your averages reflect five people. Note the response rate when presenting results and ask yourself who is not speaking up and why.
A facilitator's perspective on what actually changes teams
The conventional wisdom says the retrospective format is what matters: pick the right activity, use the right template, and the team improves. After running survey-backed retros across a range of team types, the format turns out to be almost irrelevant compared to two things: whether the team believes the survey is genuinely anonymous, and whether they have seen a retro action actually stick.
Most teams have been burned by retros that produced a list of improvements nobody owned. The survey does not fix that on its own. What fixes it is the discipline of writing one experiment, naming one owner, and checking it at the next retro before anything else. The survey just makes the conversation faster and more honest by doing the "gather data" phase before everyone is in the room.
The other thing most articles miss: quieter team members almost always have the most useful feedback. They just will not say it in a group. A pre-retro survey sent 48–72 hours before the session is the single highest-leverage change a facilitator can make, not because of the questions, but because it gives introverts a private channel.
SwarmStack makes survey-informed retrospectives easier to run
Running a survey-backed retro well requires three things most teams handle in three separate tools: distributing the survey, capturing the action items, and tracking whether those items actually get done. SwarmStack brings all three into one session.
With SwarmStack, you share a single invite link before the retro, team members contribute responses and insights in real time, and the session output, including committed experiments and owners, is versioned and exportable directly to GitHub or Jira. No copy-pasting from a form into a ticket.
- Fast distribution: one link, no account required for participants, responses collected before the retro starts.
- Visible actions: every committed improvement is captured in the session record with an owner attached.
- Audit trail: versioned deliverables mean you can check follow-through at the next retro without relying on memory.
See SwarmStack's plans to run recurring, survey-backed retrospectives at scale, or explore the platform to try a retro template in-session today.
Sources
- Conducting a sprint retrospective
- Sprint Retrospective: Formats, Questions, and Examples
- Team retrospective questions template: better lessons after projects and sprints
- 50+ Retrospective Questions to Spark Meaningful Team Discussions
This article provides general guidance on retrospective survey design and Agile practices. Confirm current Scrum framework standards with Scrum.org or a certified Agile coach for your specific context.