Ask your Scrum or Kanban team 35 questions about how agile is working
An agile team satisfaction survey asks the people on a Scrum or Kanban team how well their way of working is working for them. Its core 12 rates sprint goals, releases, contact with users, say over the work and support from outside the team, and takes about four minutes.
- 35questions
- 12in the core set
- 4 minto answer the core
- 5team factors covered
By Michael Hodge, BSc Psychology Updated September 2026
All 35 agile team survey questions
Q1 to Q12 are ticked already and suit any agile team. The sets below add Scrum events, the five Scrum values, users and the product owner, and agile working across the organization. Under each item sit its answer choices and a note for the scrum master on reading a low score.
The core 1212 questions
Ten statements cover overall satisfaction, the five factors that most separate effective agile teams, and a pace people can keep. A vote picks next quarter's focus and one open question collects ideas.
-
Overall, I am satisfied with how this team works.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe headline number to track from quarter to quarter. Read it last: the nine statements after it usually explain why it sits where it does.
-
Every sprint has a goal the whole team could explain.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeShared goals. Without one, a sprint becomes a list of tickets and nobody can say which to drop when time runs short.
-
Work is split into small pieces before we commit to it.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeRefinement. Small items finish inside the sprint, so plans hold and feedback comes back sooner.
-
We get finished work in front of users often enough to learn from it.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeRelease rhythm. Work that waits months for a release cannot be corrected by what users say about it.
-
I know who uses what we build and what they need from it.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeConcern for stakeholders had the strongest direct link to team effectiveness in a study of 1,978 Scrum teams.1
-
The team decides how to do its own work.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeSelf-management. In the same study, autonomy was the strongest driver of a team improving the way it works.1
-
I can admit a mistake to this team without worrying about it.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeSafety to speak up. Where it is low, retrospectives only surface the problems that are safe to mention.
-
Improvements we agree on in retrospectives get done.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeFollow-through. A team that discusses the same problem every sprint soon stops raising it.
-
Managers outside the team clear obstacles we cannot clear ourselves.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeManagement support. It helped teams mainly by widening their autonomy and room to improve, not by making them faster directly.1
-
I rarely have to work late to finish what the team committed to.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeSustainable pace, one of the principles behind the Agile Manifesto. A high Q1 with a low score here means overtime is holding things together.3
-
What would help this team most next quarter?
Clearer sprint goalsMore contact with usersReleasing more oftenMore say over how we workMore help from outside the teamOne vote each. The biggest pile names the first experiment, and the question works as a quick live poll at the retro.
-
What is one thing that would make this team a better place to work?
Open answerOne idea per person. Sorted into three or four themes, the answers usually explain the lowest statements.
Scrum events: worth the time?6 questions
For Scrum teams. Each statement tests an event against the purpose the Scrum Guide gives it, so a low score says which meeting to redesign.
-
Sprint planning ends with a plan we believe in.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeA plan people doubt on day one gets quietly renegotiated all sprint. Read it next to Q3 on small pieces of work.
-
The daily stand-up changes what we do that day.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe Daily Scrum exists to adjust the next day's plan. A status report to a manager fails this test.2
-
Sprint reviews are working sessions, not slide shows.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe Scrum Guide warns against limiting the review to a presentation. Stakeholders who only watch give little feedback.2
-
Our retrospectives tackle the problems that matter most.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeRetros that stay on easy topics produce easy actions. Compare it with Q7: low safety usually sits behind a low score here.
-
Refinement leaves next sprint's work ready to start.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeRefinement is where small, clear items come from. If it fails, planning turns into a long design meeting.
-
Which event would you change first?
Sprint planningDaily stand-upSprint reviewRetrospectiveBacklog refinementPoints to one meeting to rework before the next survey. It also makes a fast vote at the end of a retro.
The five Scrum values5 questions
One statement for each value the Scrum Guide names: commitment, focus, openness, respect and courage. Useful when a team has the events in place but something still feels off.
-
People on this team do what they say they will do.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeCommitment, asked about people rather than about hitting a forecast. Low scores often trace back to overloaded sprints.
-
During a sprint, side requests do not pull us off our goal.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeFocus. If this is low, find out who sends the side requests and route them through the product owner.
-
We tell stakeholders about problems, not only progress.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeOpenness. Teams that only report good news get surprised stakeholders and lose trust at the worst moment.
-
Team members treat each other as capable professionals.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeRespect. A low score here needs a private conversation with the scrum master, not a team discussion.
-
Someone here will speak up when a plan looks wrong.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeCourage. It is the early warning for failed sprints, and it depends on Q7.
Users, stakeholders and the product owner4 questions
Add these when Q5 is low, or when the team builds for people it rarely meets.
-
When did you last see or talk to someone who uses what we build?
This weekThis monthIn the last 3 monthsLonger agoNeverA date is harder to round up than an opinion. Many "Longer ago" and "Never" answers explain a low Q5.
-
Stakeholder feedback changes what we build next.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeFeedback that arrives but never reorders the backlog teaches stakeholders to stop giving it.
-
The product owner explains why top items come first.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreePeople who know the reason behind the order make better trade-offs in the middle of a sprint.
-
The product owner decides without waiting for sign-off.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe Scrum team study found that a team's say over how it works and its say over what it builds behaved as separate things, so ask about both.1
Agile working outside the team5 questions
For organizations moving several teams or departments to agile ways of working. These show where the rest of the business still runs on the old rhythm.
-
Teams we depend on can respond within the same sprint.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeOne slow dependency turns a two-week sprint into a two-month delivery. Ask which teams, in the open question.
-
Budget and approval steps let us change plans when we learn something.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreePlans fixed a year ahead fight short cycles. A low score is a case to put before finance, not before the team.
-
How much of your week goes to work outside the team's sprint?
Almost noneUp to a dayOne to two daysMore than two daysSupport tickets, other projects and meetings the sprint plan never sees. It often explains a low Q10.
-
Leaders judge us on outcomes, not on hours or ticket counts.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeWhen velocity becomes the scoreboard, estimates grow and the number stops meaning anything.
-
Training and coaching gave me what I need to work this way.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeNew ways of working take practice. Low scores among newer members, split by Q34, point to onboarding.
About you (optional)3 questions
Add these only if the survey goes to several teams at once. Inside a single team of seven, a role split points at one person, so leave them out.
-
Which best describes your role on the team?
Developer or engineerTester or QADesigner or analystProduct ownerScrum master or agile coachPrefer not to sayDifferent roles see the same team differently. The split shows whose view is missing from the totals.6
-
How long have you been on this team?
Under 6 months6 to 12 months1 to 2 yearsOver 2 yearsNew members often score autonomy and safety lower while they find their feet. Read their answers apart from the rest.
-
Which way of working does your team mainly use?
ScrumKanbanA mix of Scrum and KanbanA scaled framework such as SAFeNo named frameworkLets a department compare frameworks, and tells you which teams can skip the Scrum events set.
The five factors behind the core 12
The core follows one of the largest survey studies of Scrum teams: 4,940 people in 1,978 teams, surveyed between 2020 and 2021.1
| Factor | What it looks like on a healthy team | Core questions |
|---|---|---|
| Responsiveness | Work is sliced small and reaches users every sprint or two | Q3, Q4 |
| Concern for stakeholders | Everyone knows who the users are, and sprints have a goal that serves them | Q2, Q5 |
| Continuous improvement | People admit mistakes, and retro actions actually happen | Q7, Q8 |
| Team autonomy | The team chooses how it works and has the skills to finish | Q6 |
| Management support | People outside the team remove what the team cannot | Q9 |
Verwijs and Russo found that these five factors together explained 57.9% of the variation in how satisfied stakeholders were with a team, and 34.9% of the variation in team morale.1 Two of their findings shape how to read your results. Autonomy was the strongest driver of continuous improvement, and support from managers worked mostly through autonomy, improvement and stakeholder focus rather than by speeding the team up on its own.1 So when Q9 is low, read Q6 and Q8 alongside it.
Satisfaction is the other half of the picture. In a study of 252 software professionals, using agile practices went with more favourable views of the job and with higher job satisfaction.4 Q1 asks about satisfaction outright, and Q10 checks that it is not being paid for with late nights.
Running it so the team trusts the numbers
Four habits that keep the answers honest and turn them into changes the team can see.
Once a quarter, with a pulse in between
Sprints last a month or less,2 so a quarter gives the team three to six sprints to change something before you ask again. Send the full survey a few days before a retrospective and keep it open for a week, then use the one-minute five mid-quarter. The Scrum Guide gives the retrospective one job, to plan ways to increase quality and effectiveness,2 and this survey hands that meeting its agenda.
Keep each team's results with that team
Spotify built its squad health check for the team first, with managers and coaches as a second audience. Its authors warned that models like it can become a tool managers use to judge teams and pit them against each other, until teams hide their problems to look good.5 Share a team's results with that team, compare it with its own last quarter, and never rank teams on one chart. There is a statistical reason too: in the Scrum team study, 51% of the variation in answers came from which team people were on.1
Ask the product owner and scrum master as well
Send it to everyone on the team, not only the developers. A survey of 477 people in 71 agile teams found that teamwork quality predicted team performance when members and team leaders rated performance, but hardly at all when product owners did.6 Roles see the same team differently. When one survey covers several teams, the role question (Q33) shows whose view is missing.
Bring two statements to the retrospective
Put the chart on the screen, mark the two weakest statements and ask what is behind them. Agree on one experiment for each with a date to check it, then re-ask those two at the next pulse. A team that watches its answers become a change is more candid the next time round.
Starting a retrospective? Put Q11 up as a live team poll and let everyone watch the vote build before the discussion begins. New to polls in stand-ups and reviews? If polls are new to your stand-ups, how to make a poll explains setup for a sprint review or a planning call.
A chart of the ten statements for your retro
For Q1 to Q10, key in the team head count on every point of the five-point scale. Agreeing always signals a healthy team here, so the next experiment sits among the smallest bars.
- 1Each bar is one statement, and its length is the proportion of the team who agreed or strongly agreed. It redraws as you type.
- 2Read Q1 last. The other nine statements usually explain why satisfaction sits where it does.
- 3Hold the two lowest bars up against the Q11 vote. If the vote backs them, next quarter's experiment has chosen itself.
- 4Print a copy for the team room. Next quarter, set the new chart beside it and look for bars that moved by two people or more.
Agile team results
Reading one team's results
Made-up answers from a seven-person team after its first quarter of two-week sprints.
| Core statement | Agree or strongly agree (of 7) |
|---|---|
| Q1 Satisfied with how the team works | 4 |
| Q2 Sprint goal the whole team could explain | 6 |
| Q3 Work split into small pieces | 5 |
| Q4 Finished work reaches users often | 2 |
| Q5 Know who uses what we build | 3 |
| Q6 Team decides how to work | 6 |
| Q7 Can admit a mistake | 6 |
| Q8 Retro improvements get done | 3 |
| Q9 Managers clear outside obstacles | 2 |
| Q10 Rarely work late | 4 |
With seven people, one changed answer moves a statement by about 14 points, so look for gaps of two people or more. This team runs itself well: goals, safety and autonomy are strong. Its work rarely reaches users, though, and few people know who those users are. The Q11 vote agreed, with four votes for releasing more often. A low Q9 next to a low Q4 suggests the release is held up outside the team, and a low Q8 says past retro actions on it went nowhere.
Take Q4 and Q9 to the next retrospective and invite whoever owns the release process. Agree on one experiment, such as a monthly release to a small group of users, with a date to check it. Run the core 12 again in three months and put the two tables side by side.
A one-minute pulse to open the retrospective
Ask these mid-quarter, at the start of a retrospective, to see whether anything has moved since the full survey. They track satisfaction, users, say over the work, safety and follow-through.
- 01Overall, I am satisfied with how this team works.
- 02I know who uses what we build and what they need from it.
- 03The team decides how to do its own work.
- 04I can admit a mistake to this team without worrying about it.
- 05Improvements we agree on in retrospectives get done.
Three homemade agile questions, asked better
Three questions that turn up in most homemade agile surveys, and what we ask instead. The survey questions library covers every other topic.
How agile is our team?
Work is split into small pieces before we commit to it.
We get finished work in front of users often enough to learn from it.
Ask ten people what agile means and you get ten definitions. A practice someone has watched happen gives the team an answer it can act on.
How effective are our agile ceremonies?
The daily stand-up changes what we do that day.
Sprint reviews are working sessions, not slide shows.
Five events in one question. Someone who likes the retro and dreads planning has no honest answer, so ask about each event by its purpose.
Does management give the team enough freedom and support?
The team decides how to do its own work.
Managers outside the team clear obstacles we cannot clear ourselves.
Freedom and backing from managers are separate. A team can have plenty of one and none of the other, and one score hides which is missing.
Pen-and-paper sheets for an in-person retro
In a room together, paper can feel safer than a laptop. Give each person a copy as the retro opens and gather the sheets face down before anyone speaks.
One copy per person and a folder to collect them in is all a retro needs.
Agile team questionnaire
Page one prints Q1 to Q12, ready to tick in pen. Scrum events, values, users, agile working and the about-you questions take up the pages after it.
Download PDF
Agile team results worksheet
Count the paper answers for Q1 to Q10, work out how many agree with each, tally the Q11 vote and write down two experiments for next quarter.
Download PDFWhat scrum masters and coaches ask
Short answers for whoever sends the survey.
What questions should an agile team survey include?
Start with how satisfied people are with the way the team works, then ask about the conditions behind it: clear sprint goals, small work items, frequent releases, contact with users, say over the work, safety to admit mistakes, retro follow-through, help from outside and a pace people can keep. End on a vote and a single open question. The core 12 follows exactly that pattern.
How often should you survey an agile team?
Run the full survey once a quarter and the one-minute five mid-quarter. A quarter is long enough for a change to show up in the answers and short enough that people still remember what the last survey said.
Should an agile team survey be anonymous?
Yes. Collect answers through a link with no name field, and have the scrum master or coach share only the team totals. Inside one small team, skip the role and tenure questions, because a single role can point to a single person.
What is an agile team health check?
Usually a workshop: the team rates itself on a set of topics, often with traffic-light colours and an arrow for the trend, then talks through the results. Spotify's squad health check is the best-known model.5 This survey is the written, anonymous version, and many teams send it before the workshop so the discussion starts from everyone's view.
Can I send this before every retrospective?
The core 12 is built for a quarterly check. For a short check after every sprint, use the sprint retrospective survey on SuperSurvey, our sister site.
Can non-software teams use these questions?
Yes. Marketing, HR and operations teams that plan in sprints or on a Kanban board answer them the same way. In the builder, swap "users" for "customers" or "the people we serve" where it reads better, and browse our business survey question library for more.
Ask your team before the next retrospective
Drop all twelve core items into the builder, send the link a few days before the retro and bring the chart to the meeting. Print the questionnaire if the team meets in person.
