Product and engineering · Answered by Golden Section from more than 400 B2B software companies observed
Measure what the team delivers against what it committed to, not how busy it looks. Four measures do most of the work: the share of sprints that finish every committed story, defects that escape to production, how fast production defects are fixed, and how often you release. Aim for 70–80% of sprints finishing every committed story. Read them as trends for the same team over time, never as comparisons between engineers. When delivery is slow, find which stage is slow before blaming the engineers: stories that were not ready, scope that changed mid-sprint, rework from QA, or the build itself. Lines of code and hours measure input, not output. Next step: report the successful sprint ratio and escaped defects for the last six sprints at the next leadership meeting.
Judge engineering on output against commitments, read as a trend. When the trend worsens, find the stage that broke before changing people or adding headcount.
| Metric | Value | What it means | Source |
|---|---|---|---|
| Successful sprint ratio target | 70–80% | share of sprints that finish every committed storyread as a trend for the same team; well below the band, find which stage broke before changing people | Golden Section operating viewGolden Section operating view |
| Sprint length | 2 to 4 weeks | fixed timebox for each sprint, closed when the time is up whether or not every story is finishedthe play's sprint metrics also include story points per sprint, successful sprint ratio and defects per release | Golden Section playbookProduct Engineering Process |
| Production defect fix target | within 48 hours | production defects fixed efficiencyone of the play's recommended sprint metrics | Golden Section playbookProduct Engineering Process |
| AI adoption and delivery | 90% of respondents use AI at work | survey of nearly 5,000 technology professionalsAI adoption now shows a positive relationship with delivery throughput and a continued negative relationship with delivery stability | External benchmarkGoogle Cloud, 2025 DORA Report: State of AI-assisted Software Development |
| Communication paths in a team | 10 at 5 people; 105 at 15 | n(n-1)/2 pairs of people who may need to coordinatearithmetic behind why delivery per engineer falls as an unstructured team grows | IllustrativeGolden Section calculation |
Engineering productivity is hard to see from outside, which tempts founders toward numbers that are easy to count. Lines of code, hours logged and tickets closed all measure effort, and a team that is measured on effort will produce more of it. What a company buys from engineering is working software delivered when promised, at a quality customers do not notice. The product engineering process builds the measures for that into the sprint: a fixed timebox, sized stories, a successful sprint ratio, and defect counts by release.
When delivery slows, the cause is usually upstream or downstream of the code. The dev org chart lists where errors come from: faulty requirements, miscommunication from customer to analyst, a bad user story, an engineer missing the story, or QA missing a defect. Root-cause the slip against that list. Teams also slow as they grow, because coordination grows faster than headcount, and the fix is smaller teams around modules with clear owners, not more people. The 2025 DORA research adds a current caution: AI tools raise throughput, but without strong testing and version control they also raise instability.
The numbers are invented. A founder feels engineering has slowed since the team grew from six to twelve. Six sprints of data show the successful sprint ratio fell from 75% to 40%, while escaped defects stayed flat. Tagging every unfinished story shows two-thirds were changed after the sprint started, mostly by requests from sales, and a quarter started without acceptance criteria. Coding speed was not the problem. The company stops mid-sprint changes, routes urgent requests to the next sprint or a quick-fix process, has the business analyst sign off that stories are ready, and splits the twelve engineers into two teams around modules. Within a quarter the ratio is back above 70%.
Very small teams, two or three engineers, produce noisy sprint metrics; read them over a quarter and talk to the team. Research-heavy work such as a new AI capability will miss sprint commitments by nature and should be timeboxed as an experiment rather than measured as delivery.
From the Golden Section mistakes list, each paired with the play that prevents it.
Measuring input cost, such as hours or lines of code, instead of output is the most common way to misread engineering.
Breaking sprints to fit in one more request destroys the commitments productivity is measured against.
Engineers who do not QA their own work push rework downstream, where it looks like slow delivery.
In the order we would run them. Each is on its own page, most with a free Excel template.
Installs fixed sprints and the metrics that show delivered output.
Gives each stage an owner so a slip can be traced to where it happened.
Applies plan, do, check, act to the release process and keeps proof that it was followed.
Keeps a growing team from slowing down to rediscover how the code works.
Puts engineering's headline metrics in front of the leadership team every week.
Development plays The engineering process, org chart and documentation plays behind every productivity measure.
Compare delivery with the team's own commitments and its own past, not with a feeling. A successful sprint ratio falling below 70–80%, rising escaped defects or slower defect fixes are evidence; a founder's frustration is not. Then find which stage broke before deciding whether the problem is people, process or product management.
Coordination grows faster than headcount: five people have 10 possible pairs to coordinate, fifteen have 105. More code, more reviews and more dependencies between stories follow. Smaller teams organized around modules, ready user stories and documented code keep the slowdown in check.
They are a good complement once you release often: deployment frequency, lead time for changes, change failure rate and time to recover. For most $1M to $8M companies, sprint completion and escaped defects are the first measures to get right, and DORA's measures follow as release automation matures.
Reviewed by Dougal Cameron, CEO & Co-Founder on 2026-10-22. Golden Section observations are labeled separately from external benchmarks and illustrative arithmetic.