Developer Experience Survey Template (DevEx, SPACE, DORA)

Developer Experience Survey: [Organisation] [Survey cycle]

Survey instrument and results report for measuring developer experience: objectives, the framework mapping (DevEx feedback loops, cognitive load and flow state; SPACE dimensions; DORA capabilities), privacy and anonymity rules for survey data, administration, an original question bank, the analysis method, a results report with worked data, and the action plan. Concepts follow the DevEx (ACM Queue, 2023) and SPACE (ACM Queue, 2021) frameworks and the DORA capability catalogue at dora.dev (CC BY 4.0). Replace every [bracketed] value and every row marked Example. Privacy sections describe common practice under the EU GDPR (Regulation (EU) 2016/679); this is a documentation format, not legal advice. The worked example uses Corvid Commerce, a fictional SaaS company.

Document control

Approvals

Revision history

Contents

Part A: Instrument

1. Purpose and objectives
2. Framework mapping
3. Privacy, anonymity and data handling
4. Population, sampling and administration
5. Question bank
6. Analysis method

Part B: Results

7. Results report
8. Findings
9. Action plan
10. Communication and follow-up
11. Glossary and references

1. Purpose and objectives

The survey measures how developers experience their daily work, to find the friction that slows delivery and harms well-being, and to check whether improvement work is helping. It complements system data such as the DORA delivery metrics: systems show what happened, people explain why and reveal friction that no tool records.

Out of scope: individual performance assessment, engagement topics already covered by the company-wide HR survey, and compensation.

2. Framework mapping

The instrument uses three complementary lenses. Their concepts are summarised here in original words; read the cited articles for the full argument.

Other published frameworks exist, such as the DX Core 4. If you adopt one, map its dimensions to the item IDs in section 5 instead of running a second survey.

3. Privacy, anonymity and data handling

3.1 Principles

The following rules are binding for everyone who designs, runs or analyses the survey:

1. PRV-01 Participation MUST be voluntary. Non-participation MUST NOT be recorded, reported to managers or followed up individually.
2. PRV-02 Results MUST NOT be used for individual performance evaluation, promotion, compensation or disciplinary decisions.
3. PRV-03 Results MUST be reported only for groups of at least the minimum reporting group size (Example: 5 respondents). Smaller groups are merged into the next level up.
4. PRV-04 Demographic questions MUST be limited to what the analysis plan needs. Combinations of attributes that create a group below the minimum size MUST be suppressed in every view, including filters in dashboards.
5. PRV-05 Raw responses MUST be accessible only to the named raw data custodian and a deputy. Managers MUST NOT receive raw data or free-text comments attributed to a team below the minimum size.
6. PRV-06 Free-text comments MUST be screened before sharing to remove names, unique events and writing that could identify the author.
7. PRV-07 Raw data SHOULD be deleted or irreversibly aggregated within the retention period in 3.3.
8. PRV-08 Respondents MUST receive a privacy notice before the first question, stating purpose, data collected, who sees what, retention and contacts.

3.2 Anonymous or confidential

Decide which promise you make and use the correct word with respondents.

Under the GDPR, information that cannot be related to an identifiable person is outside its scope (see Recital 26), but data that is only pseudonymised remains personal data. A survey that collects team, role and tenure for a small group is rarely anonymous in fact. Check with the data protection officer which model applies.

3.3 Data handling record

3.4 Privacy notice text (original, adapt before use)

This survey asks about your experience of building and shipping software at [Organisation]. It is voluntary and takes about [12] minutes. Answers are [anonymous / confidential]: nobody outside [custodian team] sees individual answers, and results are shown only for groups of [5] or more people. Results are never used to evaluate individuals. Raw answers are deleted after [24] months. Questions: [contact]. Privacy contact: [DPO contact].

4. Population, sampling and administration

4.1 Timeline

5. Question bank

Scale unless stated: five-point agreement (1 strongly disagree, 2 disagree, 3 neither, 4 agree, 5 strongly agree), plus "not applicable". Reference period for all items: the last three months.

5.1 Feedback loops (DevEx)

5.2 Cognitive load (DevEx)

5.3 Flow state (DevEx)

5.4 Satisfaction, collaboration and culture (SPACE and DORA)

5.5 Delivery practices (DORA perception)

5.6 AI-assisted development module (optional)

5.7 Open questions and segmentation

Do not ask for team name, location, age, gender or exact job title unless the analysis plan needs it and the privacy review approved it.

6. Analysis method

1. Response rate: responses / invited, overall and per reporting group. Flag groups below the target response rate.
2. Favourable score per item: share of answers 4 or 5 among valid answers (excluding "not applicable"). Also report unfavourable (1 or 2).
3. Dimension score: mean of the favourable scores of the items in the dimension, reported to whole percentage points.
4. Margin of error for a favourable share at 95% confidence, with finite population correction: MoE = 1.96 * sqrt(p * (1 - p) / n) * sqrt((N - n) / (N - 1)), where n is responses, N the population and p the share. Use p = 0.5 for the worst case.
5. Meaningful change between cycles: compare the two shares as a difference of proportions. Its margin of error at 95% confidence is MoE_diff = 1.96 * sqrt(p1 * (1 - p1) / n1 * fpc1 + p2 * (1 - p2) / n2 * fpc2), where fpc = (N - n) / (N - 1) for each cycle; this equals sqrt(MoE_1^2 + MoE_2^2), about 1.4 times the single-cycle margin when both cycles are similar. Treat a change as real only when it exceeds MoE_diff and the group has at least 20 respondents in each cycle; otherwise label it "within noise". Because many people answer both cycles, the samples are not independent; the formula then overstates the noise slightly, which keeps the rule conservative. Dimension scores are means of item shares; use the item formula as an approximation for them and say so in the report.
6. Drivers: rank items by correlation with DX-EFF-01 or DX-SAT-02 to find which friction matters most; treat this as a pointer, not as proof of cause.
7. Free text: two people code comments independently into themes, agree a codebook, and report theme counts; quote only screened comments (PRV-06).
8. Triangulation: compare perception with system data in the Software Delivery Performance Report; investigate disagreements.
9. Suppression: apply PRV-03 and PRV-04 before any table leaves the custodian.

7. Results report

7.1 Participation

Example (Corvid Commerce, Q3 2026): 168 of 240 invited people responded, a response rate of 70.0%. The worst-case margin of error for an organisation-wide favourable share is 1.96 * sqrt(0.25 / 168) * sqrt(72 / 239), which is about ±4.1 percentage points (4.15 before rounding). For a change between two cycles of this size, the worst-case margin of the difference is about ±5.9 points (sqrt(2) * 4.15), assuming the last cycle also had about 168 responses.

7.2 Dimension scores (organisation)

7.3 Items to watch

7.4 Segment view

With 12 respondents, one answer moves a share by about 8 percentage points; read the Payments column as a signal that agrees with the system data (manual rollback known by one engineer), not as a precise value.

7.5 Free-text themes

Check: 38 / 131 = 29%, 27 / 131 = 21%, 15 / 131 = 11%.

8. Findings

9. Action plan

Actions DXA-01 and DXA-02 are the same work as ACT-2026Q3-02 and ACT-2026Q3-01 in the delivery performance report; track them once and cross-reference.

10. Communication and follow-up

Review the question bank once a year: retire items that never inform a decision, check wording with a pilot, and record changes as a new question bank version.

11. Glossary and references

11.1 Glossary

11.2 References

Standard and licence note

Based on the concepts of the DevEx framework (ACM Queue, 2023) and the SPACE framework (ACM Queue, 2021), cited for their dimensions only with no text reproduced, and on capability names from the DORA capabilities catalogue published at dora.dev by Google LLC under the Creative Commons Attribution 4.0 International licence (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/). The question bank is original wording written for this template. Privacy references to the GDPR are paraphrased; this is a documentation format, not legal advice, so check the consolidated text and national employment rules with your data protection officer. DX Core 4 is named only. Google, DORA, ACM and DX are trademarks of their owners; this template is not affiliated with or endorsed by them. This template is original text written for this collection. Check the current official versions before use. Template licence: MIT.