Retrospective Survey Template

Invite the people who worked in the named sprint, explain who will read responses and use the answers to prepare a conversation—not to score individuals. Lehtinen, Itkonen and Lassenius examined 37 team retrospectives over almost three years in a large distributed software organization. Their abstract says “Most discussions were related to topics close to and controllable by the team.” Read the university abstract . The authors also warn that strong opinions without hard evidence may not reflect reality. That is why this example asks for observed work, checks a prior action and separates team-controlled changes from issues needing escalation. This seven-item SurveyLegend form is not a validated retrospective method.

Send it near the end of one named sprint, before a facilitated team discussion. Q1 anchors the period; Q4 and Q5 stop prior commitments disappearing; Q6 and Q7 turn a complaint into an action path. A project-wide closeout needs SurveyLegend's post-project assessment survey instead. The agile maturity form asks about broader working practices, not one sprint's next change.

Every question is optional and always shown. Answer about the same named sprint. Use specific examples without naming or judging colleagues. Q4 can be skipped if there was no prior action; Q5 has an explicit option for that case.

Name the sprint and dates, team and meeting date. Tell respondents whether answers are attributed; do not promise anonymity in a small team unless it is real. If the team does not work in sprints, replace the period consistently throughout the questionnaire rather than mixing sprint and project language. Keep one proposed next change small enough to test. Do not silently turn qualitative feedback into a person-level performance measure. Bring delivery evidence to the discussion when a repeated claim can be checked, and agree who will follow up outside this form.

Use the precise seven-item specification to draft a pre-meeting questionnaire, then verify the sprint and the team's response-handling plan.

Group Q2 and Q3 by observable workflow, not by who wrote the comment. Compare Q4 with Q5: an untried action needs an ownership conversation, while a tried action that did not help may need revision. Take Q6 as a proposed experiment, then use Q7 to decide whether the team can act or must escalate. Record the decision and check it next sprint; the survey itself does not assign tasks or prove a process change worked. If the work is a completed multi-phase project, use the post-project assessment template.