Your Delivery Forecast Is Missing the Work That Is Getting Old

A delivery review can look like this. Velocity is stable, the burnup line still climbs, and most of the sprint scope sits in progress or done. Nobody brings bad news because the view does not expose item-level age. Five weeks later the release date moves, and the retrospective finds three items that had been open since before the quarter started. This is a hypothetical pattern, not a client case.

Nothing in those completion metrics was necessarily wrong. Velocity and throughput describe work that closed. A dashboard can still obscure risk when it does not show the age and context of work in progress. The items that may decide whether a commitment holds are still inside the system, and their age is one signal worth inspecting.

Two items in the same column are not the same bet

Open any board and pick two tickets in the same status. One was pulled in yesterday. The other has been sitting there for eleven weeks. In a completion percentage they weigh the same, and on a status slide they get the same color.

When an item has already run far past what comparable items normally take, it deserves a closer look. The scope may have grown. It may be waiting on a decision that nobody in the room has the authority to make. It may need the one specialist who is also sitting on three other critical paths. It may have been paused in March while the card stayed exactly where it was. Elapsed age will not tell you which explanation applies. It tells you not to read an item at this age the same way you read one that started yesterday. The team's own record of how long comparable items ran is the reference to check against.

What the research actually supports

The evidence here is narrower than the folklore around it. It supports using live issue information in forecast review. It does not isolate the incremental predictive value of elapsed age.

Choetkiertikul et al. (2017) built models that predicted whether issues with due dates would be delayed, using data already present in issue trackers across eight open-source projects. The models performed well enough to be worth attention, but the useful part for a delivery lead is the timing. Risk was visible from the state of work in flight, before a date had been missed. A later study extended the same logic from single issues to whole iterations, predicting delivery capability while the iteration was still running (Choetkiertikul et al., 2018).

Both studies are observational and drawn from open-source repositories, so they need calibration before they mean anything in a specific commercial context. Neither one isolates elapsed age as the driver, and neither compares an age-aware forecast against an otherwise identical forecast that ignores age. They support updating a forecast from in-flight data. They do not show that an aging column on a board makes dates hold.

Pasuksmit et al. (2022) offer one concrete reason a plan may drift after work starts. Across nearly twenty thousand work items in seven projects, a minority had their story points revised after they were already assigned to a sprint, and those revisions usually moved the estimate upward. Changed-point items were often associated with information changes related to scope updates, while items whose estimate stayed stable showed a closer relationship between the estimate and the actual development time. An aging review may surface this kind of instability, but that transfer is a hypothesis rather than a tested chain. The study shows instability weakening plan reliability, not chronological age causing scope to change.

Before anyone turns this into a management report, read Flournoy et al. (2025). They analyzed more than fifty thousand cycle-time observations from over two hundred organizations and found substantial variation within individuals, between individuals, and between organizations. The tested associations were modest, much variation remained unexplained, and one observation offered limited signal about the person behind it. Cycle time, as their title has it, is messy rather than magic. Treat it as a noisy systems signal, not a score for ranking individuals.

Live issue information can inform a forecast review before a date fails. Comparing active-item age with a team's historical cycle-time distribution can help choose what to investigate, but the selected evidence does not establish elapsed age as a standalone predictor or show that an aging review improves forecast accuracy.

A 30-minute aging review you can run on Monday

Take one team and one class of work. Pull the completed items of that type from the last few months and calculate the cycle-time percentiles. Use the same start, finish, and intentional-pause rules for active and completed items. This is a local reference, not a service-level guarantee: it exists so that the word "unusual" means something specific in your organization instead of something political.

Then list every active item of that type and put its current age next to the distribution. Most items will look ordinary. Discuss only the handful that do not.

For each unusual item, ask what happened rather than who is slow:

• Has the scope changed since it was planned?

• Is it waiting on another team, a vendor, or an environment?

• Is a decision blocked, and with whom does it sit?

• Is it queued behind other work the same person is carrying?

• Was it paused on purpose, and does anyone still want it?

• Or is the card simply wrong, and the work finished three weeks ago?

Pick one system-level intervention for the session. Split the item, escalate the decision, remove the dependency, pair someone in, or stop the work outright. One intervention that actually happens beats five that get minuted.

Update the forecast only if the review produced new information. If the outliers turn out to be recording quality, the forecast held up and your board did not. If two of them are waiting on the same architecture decision, the forecast was optimistic and you now know the reason.

Run this as an experiment with a review date. Four to six weeks is enough to decide whether to keep it. Nothing in the evidence promises a more accurate forecast, and I am not claiming one. What it can change is the timing of the conversation, so that the awkward questions arrive while there is still room to act on the answers.

One caution before you build the report. When elapsed age appears in a personal review or team comparison, it risks becoming a target. Cards may be closed and reopened, or work split to reset the clock. A signal intended to examine the system can then become a signal about who is being watched and lose its value for delivery decisions.

So on Monday, open the board and find the oldest active item that nobody mentioned in the last review. Ask what it has been waiting for. Someone in that room usually knows, and has simply never been asked out loud.

References

Choetkiertikul, M., Dam, H. K., Tran, T., & Ghose, A. (2017, January 19). Predicting the delay of issues with due dates in software projects. Empirical Software Engineering, 22(3), 1223–1263. https://doi.org/10.1007/s10664-016-9496-7

Choetkiertikul, M., Dam, H. K., Tran, T., Ghose, A., & Grundy, J. (2018, June 1). Predicting Delivery Capability in Iterative Software Development. IEEE Transactions on Software Engineering, 44(6), 551–573. https://doi.org/10.1109/tse.2017.2693989

Flournoy, J. C., Lee, C. S., Wu, M., & Hicks, C. M. (2025, October 11). No silver bullets: Why understanding software cycle time is messy, not magic. Empirical Software Engineering, 30(6). Article 174. https://doi.org/10.1007/s10664-025-10735-w

Pasuksmit, J., Thongtanunam, P., & Karunasekera, S. (2022, August 10). Story points changes in agile iterative development. Empirical Software Engineering, 27(6). Article 156. https://doi.org/10.1007/s10664-022-10192-9