Compare

RACE Programming vs DORA

DORA and Accelerate measure delivery performance. RACE Programming is the operating model you adopt to move those numbers, and once an AI agent writes the code, it changes which numbers are worth watching. For the full playbook, see measuring a RACE rollout with DORA.


At a glance

A scorecard and an operating model

Dimension RACE Programming DORA / Accelerate
What it is A prescriptive Agentic SDLC framework A measurement framework and research program
Question it answers How should we build? How well are we building?
Output Roles, Stint cadence, Executable User Stories, four Definition-of-Done gates Five key metrics and a capability catalog
What it measures from Idea to production Commit to production
Relationship Complementary: adopt RACE Programming, keep the DORA five as guardrails, and read them correctly
The reframe

RACE moves the numbers, and moves which ones matter

DORA measures commit to production. AI collapses that clock, so your throughput metrics go Elite almost by construction and stop being the interesting number. Re-point your instrumentation at two things instead: quality at the Pit Stop, and the idea-to-production clock.

That is not an argument against DORA. Keep the five as guardrails; they still catch a rollout that trades quality for speed. But once execution is nearly free, the numbers that decide your pace are the ones DORA was never designed to see.

Metric mapping

How each DORA metric reads under RACE

DORA metric Under a RACE Programming rollout
Deployment Frequency Elite by construction: every Stint ends in a Pit Stop, weekly or faster. A floor you now stand on, not the win. Watch the share of Pit Stops that clear all four gates first pass
Lead Time for Changes Run two clocks: execution (EUS entering the Pit Crew to its Pit Stop, in hours) and the RACE-native clock (idea logged to Pit Stop, in days). The gap tells you the constraint is upstream
Change Failure Rate The one that still tells the truth. Controlled upstream by Gherkin acceptance criteria and the four-gate Definition of Done. Target flat or falling as throughput rises; always plot next to EUS per week
Failed Deployment Recovery Time Minutes, not hours. Everything as Code makes rollback a deterministic config revert, not a firefight
Deployment Rework Rate (the 2025 fifth key) Near zero. Each unplanned Pit Stop is a defect that slipped the gates, and the earliest signal the Definition of Done is too loose
The three metrics DORA does not have

Add these, or you are measuring the half that got easy

RACE-native metric What to measure
EUS throughput (your real velocity) Executable User Stories accepted per week, per team. Use it instead of story points and commit counts, both of which break the moment the agent writes the code
Idea-to-Pit-Stop lead time Median time from a Team Principal idea logged to its Pit Stop deploy. Once execution is free, this reflects how fast you turn intent into production
Team Principal absorption capacity (the new ceiling) EUS the Team Principal can specify and accept per week, divided by EUS the Pit Crew can ship. Target a ratio approaching 1; below 1 the client is the bottleneck

Keep the DORA five as guardrails. Manage to EUS throughput, the idea-to-production clock, and absorption capacity. DORA tells you the old bottleneck is gone; these tell you where the new one is.

Measuring a RACE rollout with DORA → · Read the framework → · More comparisons →

FAQ

Frequently asked questions

What is the difference between RACE Programming and DORA?
They answer different questions. DORA (DevOps Research and Assessment), and the Accelerate research behind it, is a measurement framework: five key metrics and a body of evidence on the capabilities that predict delivery performance. It tells you how well you deliver. RACE Programming is a prescriptive Agentic SDLC framework: roles, a one-week Stint cadence, and the Executable User Story artifact. It is what you adopt to change how you deliver. DORA is the scorecard; RACE Programming is the operating model the scorecard measures.
How do DORA metrics change under RACE Programming?
DORA still works, but a RACE Programming rollout moves most of the numbers and changes what "good" means. DORA measures the clock from commit to production, which RACE makes almost free, so deployment frequency and lead time reach the Elite band almost by construction. The metric that still tells the truth is Change Failure Rate. RACE also adds a clock DORA does not have: idea to production.
Which DORA metric matters most under RACE Programming?
Change Failure Rate. Agentic output needs a stricter review bar, not a looser one. In RACE Programming, CFR is controlled upstream by the Gherkin acceptance criteria in each Executable User Story and a four-gate Definition of Done (unit coverage, integration, end-to-end, automated acceptance) that must pass before a change reaches the Pit Stop. Always report CFR next to velocity.
What should you measure that DORA does not cover?
Three things: EUS throughput (Executable User Stories accepted per week, your real velocity), idea-to-Pit-Stop lead time, and Team Principal absorption capacity. When the delivery team can ship faster than the client can ideate and accept, the pacing metric is how many Executable User Stories the client can specify and accept per week, measured against how many the Pit Crew can ship. The gap is the real bottleneck, and DORA cannot see it.
Can we use DORA to prove RACE Programming is working?
Yes, with the right reading. Expect deployment frequency and lead time to reach Elite quickly and treat that as a floor you now stand on, not the win. Watch Change Failure Rate and Deployment Rework Rate stay flat or fall as throughput rises. Then manage to the three RACE-native metrics DORA lacks: EUS throughput, the idea-to-production clock, and absorption capacity.