Average Resolution Time: The Metric Your Velocity Chart Buries

A ticket has been "In Progress" for eleven days. Nobody flagged it in standup. Nobody escalated it. It carried over from last sprint into this one, where it sat for another week before someone finally picked it back up. The sprint velocity looked fine throughout. The ticket was simply invisible.

This is the failure mode that velocity cannot catch — because velocity only measures what gets closed, not how long things took to get there. A ticket that closes on day 14 counts the same as one that closed on day 2. The chart looks the same either way.

The metric that catches it is average resolution time: the median time from when a ticket is picked up to when it is closed. It is one of the simpler metrics in engineering, and one of the least tracked. Teams that start measuring it tend to find things they did not expect.

What resolution time actually measures

Resolution time is not just a speed metric. It is a process health metric.

A healthy team has low resolution time variance — most tickets close in a predictable window, with a few outliers at the tail. An unhealthy team has high variance: some tickets close in a day, others drag on for two or three weeks. The average might look acceptable. The distribution tells a different story.

High variance usually means one of three things. Either the team's estimation is off and some tickets are much larger than they appear. Or there are hidden blockers — external dependencies, unclear requirements, waiting for review — that nobody is surfacing. Or some engineers are working through genuinely difficult tickets while others are clearing quick wins, creating a split that team velocity will never show you.

None of these are detectable from the velocity chart alone. All of them show up in resolution time if you look at the right level of detail.

The tickets that inflate your average

In most teams, 80% of tickets close in a reasonable time. The average resolution time is inflated by a small cluster of tickets that nobody was watching.

These are the tickets that get picked up, stall halfway through, and then sit in limbo while the engineer moves on to something else. The status stays "In Progress." Nobody reassigns it. It doesn't show up in standup because nobody wants to raise a ticket that's been technically open for nine days and isn't visibly blocked.

That cluster is where your process debt lives. When you track resolution time and look at the tail — the tickets taking 10, 15, 20 days — you almost always find a pattern. They cluster around a certain type of work, a certain integration, a certain part of the codebase. Or they cluster around a dependency on a specific person or external team that is consistently slow to respond.

Finding that pattern is worth more than any sprint retrospective. It tells you exactly where to intervene.

Why resolution time drops when teams fix the right things

The teams that see the biggest improvements in resolution time are almost never the ones that told engineers to work faster. Speed is rarely the problem.

The improvements come from reducing wait time. Reviewing PRs within a day instead of three. Clarifying ticket descriptions before sprint planning instead of mid-sprint. Flagging external dependencies before a ticket is picked up instead of discovering them halfway through.

These are process changes, not performance changes. And they are only visible as a lever once you are measuring how long tickets actually take — not just how many close each sprint.

A team that ships 40 points a sprint with an average resolution time of 4 days is running a very different operation than one that ships 42 points with an average resolution time of 11 days. The second team is carrying more work in flight simultaneously, absorbing more context-switching, and hiding more in-progress risk at any given moment. The velocity numbers do not tell you this.

Tracking it without drowning in spreadsheets

The frustrating part of resolution time is that it is genuinely useful data that Linear does not surface directly. You can see when a ticket was created and when it was closed. Computing the median resolution time across sprints, filtering by team or member, watching the trend over 8 or 12 weeks — that requires an export and some manual work, which most teams skip because there are other things to do.

The metric tends to get tracked by the teams that have enough operational overhead to invest in it — which is unfortunately the inverse of who needs it most. Early-stage teams and growing engineering organizations are exactly the ones where hidden blockers and ballooning resolution times cause the most damage, because there is no buffer to absorb the cost.

If you run your team on Linear, SprintIQ tracks average resolution time automatically, week over week, without any export. You can see the trend before the average drifts high enough to become a problem — which is the only time it is still cheap to fix.

The velocity chart tells you how much your team shipped. Resolution time tells you what it cost to ship it. Both numbers matter. Most teams are only watching one of them.