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.

Does RACE Programming improve DORA deployment frequency?

Yes, by construction. In RACE Programming a Pit Stop is a production deployment and every Stint ends in one, with the default Stint at one week, flexing to about two days. So deployment frequency is weekly or faster before any improvement. Read it as a floor you now stand on, not as the win.

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?

Idea to production, and the 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.

Practice Guide · Measuring a RACE rollout

If your team runs on DORA

A measurement playbook. For each DORA metric: what to measure under RACE Programming, where to pull it from, what target to hold, and the one thing to actually watch. Plus the three RACE-native metrics DORA does not have and you now need.

The one reframe that drives all of this: 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.

The five keys, instrumented

Deployment Frequency

Measure: Pit Stops shipped per week, per Pit Crew.
Source: your CD pipeline, tagged by Stint. One Pit Stop is one Stint's production deploy.
Target: at least one per week at the default one-week Stint; two to three per week when Stints run short (about two days).
Watch: not the count, which is Elite by construction, but the share of Pit Stops that cleared all four Definition-of-Done gates on the first pass.

Lead Time for Changes (run two clocks)

Measure, execution clock: median hours from an Executable User Story entering the Pit Crew to its Pit Stop deploy.
Measure, RACE-native clock: median days from a Team Principal idea logged in the Executable Product Backlog to its Pit Stop deploy.
Source: Executable Product Backlog timestamps (idea logged, EUS accepted) joined to the deploy timestamp.
Target: execution clock in hours, not days. The idea-to-production clock is your real number; benchmark it against itself over time.
Watch: the gap between the two clocks. Tiny execution time plus a large idea-to-production time means the constraint is upstream (specification and acceptance), not engineering.

Change Failure Rate

Measure: Pit Stops that need an unplanned fix within your incident window (for example seven days) divided by total Pit Stops.
Source: incident tracker joined to Pit Stop deploys.
Control it with: the four-gate Definition of Done (unit coverage at or above 80%, integration, end-to-end, automated acceptance) plus the Gherkin acceptance criteria in every EUS. A failed gate returns to Build; nothing reaches a Pit Stop ungated.
Target: flat or falling as throughput rises. If CFR climbs, it is a gate problem, not a speed problem; tighten the gate, do not slow the agent.
Watch: always plot it on the same chart as EUS per week. A velocity gain with a rising CFR is not a win.

Failed Deployment Recovery Time

Measure: median time from a failed Pit Stop detected to service restored.
Source: incident tracker (opened to resolved), filtered to deploy-caused incidents.
Target: minutes, not hours. Everything as Code makes rollback a deterministic config revert, not a firefight.
Watch: slow recovery means your pipeline is not yet fully Everything as Code. That is the fix.

Deployment Rework Rate (the 2025 fifth key)

Measure: unplanned Pit Stops caused by a production incident divided by total Pit Stops.
Source: tag every Pit Stop as planned or unplanned-incident-driven.
Target: near zero. Each unplanned Pit Stop is a defect that slipped the gates.
Watch: this is your earliest signal the Definition of Done is too loose. When it rises, tighten the specific gate that let the defect class through.

The three metrics DORA does not have

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

EUS throughput (your real velocity)

Measure: Executable User Stories accepted (passed the Definition of Done, shipped in a Pit Stop) per week, per team.
Source: the Executable Product Backlog / delivery board.
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

Measure: median time from a Team Principal idea logged to its Pit Stop deploy (the RACE-native clock above, tracked as a first-class metric).
Why: once execution is free, this is the number that actually reflects how fast you turn intent into production.

Team Principal absorption capacity (the new ceiling)

Measure: EUS the Team Principal can specify and accept per week, divided by EUS the Pit Crew can ship per week.
Source: Executable Product Backlog (accepted-by-Team-Principal timestamps) versus Pit Crew throughput.
Target: ratio approaching 1. Below 1, the client is the bottleneck, and that is where to add Pit Wall capacity (see the staffing guide).
Why: when the team can outproduce the client, this metric sets your pace. It is the one DORA cannot see.

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.

Read the framework → · All practice guides →