In the work-tracking history of one North American education-technology client, about 47% of story time was spent waiting: in statuses where the story sits between people, such as waiting for development, blocked, or waiting for review or demo. That is from 587 timed stories (of 1,244 in the history, snapshot 24 September 2026). The median story took about 18.5 days from start to done. Separately, 36% of stories re-entered a status they had already left: a share of stories, not of time. That is why making code faster doesn't, on its own, make delivery faster.
The history covers 1,244 stories and 1,011 requirements, all human-delivered. It is our baseline for judging AI-led delivery, and we are publishing it with its limits.
Key takeaways
- Median story: about 18.5 days from start to done. Median finished requirement: about 30 days.
- About 47% of story time (587 timed stories) was waiting: finished work sitting until the next person picked it up, or blocked.
- The build step is a minority of the clock, so speeding it up helps less than it seems.
- Rework matters: 36% of the 587 stories went back to an earlier status, and those took longer.
- The fixes are upstream and in review flow: ready requirements, named gates, visible queues.
How did we measure it?
We read the status history from the client's work-tracking project, read-only, and counted calendar days. No model produced the numbers. We left out cancelled stories, technical stories and any story that started and ended within a day.
The dataset holds 1,244 stories. Every timing figure in this article, including the 47% and the 18.5 days, comes from the 587 that carry the status transitions needed to time them, finished between August 2025 and 24 September 2026. For those, the median was 18.5 days, with the quickest fifth under about 9 days and the slowest fifth over about 47. The mean was 29 days, pulled up by a long tail. For requirements, the median finished one took about 30 days, based on the 158 requirements (of 1,011) whose linked stories were all complete in the 24 September snapshot.
Where did the time sit?
We split each story's calendar days by status. Four statuses count as waiting: Development Done and QA Done (finished, not yet picked up for review or demo), Ready for Development and Blocked. That classification is ours, and the limits section says what it affects.
| Status | Share of story time | Counted as waiting |
|---|---|---|
| QA Done | 19.7% | Yes |
| In Progress | 17.1% | No |
| Development Done | 12.6% | Yes |
| QA In Progress | 9.7% | No |
| Dev In Progress | 9.0% | No |
| Ready for Development | 8.8% | Yes |
| Open | 6.0% | No |
| Blocked | 5.8% | Yes |
The four waiting statuses add up to 46.9%. The largest single block, at 19.7%, is QA Done: work that has passed testing and is waiting for the next step. Work that is finished is not the same as work that has moved on.
Why doesn't faster coding fix this?
Because the build step is a small part of the clock. Dev In Progress holds 9.0% of story time. If agents cut it to zero, the median story would still spend almost all of its remaining time in the other statuses, and most of that is waiting for a person.
Faster code can also make things worse downstream. More changes arriving sooner means more work reaching review and testing queues, and those are the statuses where stories already sit longest. We saw a version of this in our own Harness pilot, where the build was fast and the constraint moved to requirements, design and approvals. Speeding up a step that isn't the constraint yields little.
What about rework?
Of the 587 timed stories, 212 re-entered a status they had left, which is 36%. The other 375 never did. The median story with no re-entries took 15 days, with one re-entry 28 days, and with ten or more 49 days.
That doesn't prove rework causes delay, since harder stories probably bounce more and also take longer. It does show that going back is common, and it is expensive wherever it happens. The same pattern shows up in sign-off: of the 66 requirements with a recorded review, those sent back for an update took a median 27.8 days to approve, against 12.75 days for the rest. Only 66 of 1,011 requirements had a review we could time, so treat that figure as indicative.
What does help?
These are design choices, not results. We haven't yet measured how they perform, and we say so below. They follow from where the time sat.
- Make requirements ready before work starts. In AI-led delivery engagements, a requirement passes four named human approval gates before build, and a workflow rule stops a story entering Ready for Development until every field is set. The tool enforces it, with no meeting needed.
- Make review queues visible and limited. Our delivery model runs flow, not sprints, on two boards that share one status set: a Planning board for the requirement and story pipeline, and a Live board for build, test and demo. Limits apply to the review queues, because that is where waiting builds up.
- Measure from the history, not from counters. Analytics read the change log, so a story's time in each status is a fact, not a report.
This is also why our Agentic Harness Orchestration work includes a Requirements Harness, which is live with one client, and why the Application Development and Maintenance and Dedicated Teams services describe the gates and the flow model. ETA applies the same measurement-first idea across a company's workflows, and the ETA white paper explains how.
What doesn't this show?
- One client, one programme. We don't know whether 47% is typical.
- Calendar days, not effort. A story in a waiting status isn't necessarily idle work for the team, and a story in progress isn't necessarily being worked every day.
- A partial sample. Timing covers 587 of 1,244 stories, and the review figures cover far fewer.
- Our classification. We counted Done, Ready for Development and Blocked as waiting. A different rule would shift the number, and teams use statuses differently.
- An unexplained slowdown. Stories finished from April 2026 took longer than earlier ones, and we haven't explained why.
- No results yet for the new model. We have no AI-led delivery numbers to set beside this baseline. We will measure them side by side and publish them when we have enough, whichever way they fall.
- Is 47% waiting normal?
- We don't know. We have one programme and no benchmark we trust. The useful comparison is your own history, measured with a rule you set in advance.
- Does this mean AI coding tools don't help?
- No. It means that for this programme the build step was a minority of the elapsed time, so speeding it up alone moves the total less than people expect.
- How can we measure our own delivery time?
- Export the status history from your tracker, count calendar days per status, and decide in advance which statuses count as waiting. Our AI consulting team can help you do it.
If you want this view of your own delivery, our AI consulting team can run it on your tracker history. Contact us to start.
About the author
How this was written. Drafted with AI assistance from Anitech's internal working papers and edited by Jack Dinneen.
