References & Sources

ShiftQuality's articles and tutorials cite their sources. This page collects the references we lean on most, so you can go to the primary material rather than to a summary of it — and so that any figure quoted on this site can be traced.

One rule runs through all of it: a benchmark without a year is unanchored. Several of the frameworks below have revised their thresholds, their metric names, or their definitions between publications. Quoting a number without saying which edition it came from is how stale figures outlive the research that produced them.

Delivery performance

• DORA, DORA's software delivery performance metrics — the current metric set. Note that it is now five metrics, not the original four: deployment rework rate was added, covering unplanned deployments that follow a production incident.

• DORA, A history of DORA's software delivery metrics — how the metrics changed. Most consequentially, mean time to restore was renamed failed deployment recovery time in 2023 and narrowed to impairment caused by a change, because the older framing could not separate your deploy failing from a data-centre outage.

• DORA, Research — the State of DevOps report archive, 2014 onward. The elite/high/medium/low band thresholds live inside the individual annual reports and differ between years. Cite the year. One thing that regularly gets reported as a typo: on change failure rate, the high and medium clusters have shared a band in DORA's published tables. That is a finding, not an error — it is the metric that separates the top clusters least cleanly.

Developer productivity

• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, The SPACE of Developer Productivity: There's more to it than you think, ACM Queue vol. 19, no. 1 (February 2021) — doi.org/10.1145/3454122.3454124. SPACE is not DORA's successor, a conflation common enough to be worth stating plainly. It is a separate framework from Microsoft Research, GitHub and the University of Victoria; Nicole Forsgren co-authored both, which is where the assumed lineage comes from. It measures the experience and effectiveness of the people doing the work, alongside the delivery metrics rather than instead of them.

Requirements and discovery

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering — the characteristics of a well-formed requirement, including traceability upward to a stakeholder need and downward to lower-tier requirements.

• Bill Wake, INVEST in Good Stories, and SMART Tasks, 2003 — the original INVEST checklist.

• Agile Business Consortium, MoSCoW Prioritisation — the DSDM framing, the minimum usable subset, and the effort-share guidance. Those percentages are practitioner convention, not a measured result.

• Dai Clegg and Richard Barker, CASE Method Fast-Track: A RAD Approach (Addison-Wesley, 1994) — where MoSCoW was first published.

AI and LLM systems

• OWASP, Top 10 for Large Language Model Applications — prompt injection and the case for layered mitigation rather than a prompt-level fix.

Industry surveys

These get quoted constantly, including by us. They are worth citing and worth discounting at the same time: each is run or commissioned by a company selling into the market it is measuring, and none is peer reviewed. Where we use them we name the vendor.

• WRITER, with Workplace Intelligence, Enterprise AI adoption in 2026 — 79% of organisations reporting adoption challenges, 54% of C-suite leaders saying AI adoption is tearing their company apart, 29% seeing significant ROI. 2,400 knowledge workers and C-suite leaders across the US, UK, Ireland, Benelux, France and Germany, fielded 17 December 2025 to 25 January 2026. The 2025 edition is the baseline those increases are measured against.

• Composio, The 2026 AI Agent Report — 97% of executives reporting deployed agents against 12% reaching production at scale. Composio sells agent infrastructure.

A note on statistics that circulate without a source

Some of the most-repeated numbers in software engineering have no research behind them at all. They get laundered into credibility by repetition: a figure appears in a self-published post, gets quoted by a second post that describes it as "a 2026 analysis", and by the fifth citation it reads like a finding.

We have published this mistake ourselves and corrected it. Two articles on this site once led with agent-failure percentages that traced back to a single self-published write-up with no stated methodology or sample. Both have been retitled and the figures removed, with a note on each explaining why — because silently deleting a number teaches nobody anything.

If a statistic matters enough to build an argument on, it matters enough to follow to its origin. Often the trail ends somewhere that will not hold your weight.

How we handle numbers

Where a figure cannot be traced to a primary source, we soften it to a qualitative statement rather than dress it up with a citation that does not support it. Where a threshold is genuinely not published on a citable page — DORA's bands are the standing example, since they sit inside report PDFs — we say so and point you at the report rather than invent a reference.

If you find a number on this site without a source behind it, that is a defect. Tell us and we will either cite it or remove it.