The Jira Metric Every Engineering Manager Should Monitor (Hint: It's Not Velocity)
Your Sprint Isn't in Trouble When Velocity Drops
It's in trouble much earlier.
Picture this.
It's Wednesday morning.
Sprint Review is on Friday.
The Jira board looks healthy. Most stories are in progress, a few are in review, and several are already done.
Nobody seems concerned.
Then someone asks a simple question.
"How long has PAY-243 been sitting in Code Review?"
Silence.
Someone opens the issue.
Nine days.
Nobody noticed.
The reviewer assumed another reviewer would pick it up.
The developer assumed feedback was coming.
The Scrum Master assumed it wasn't blocked because nobody mentioned it during standup.
One forgotten ticket delayed the release.
Every engineering manager has experienced some version of this story.
The problem wasn't velocity.
The problem was that the team couldn't see work quietly slowing down until it became everyone's problem.
Velocity Is Useful. Just Not for Today's Decisions.
Velocity is one of the most commonly tracked Agile metrics, and for good reason.
It helps teams understand how much work they completed during previous sprints.
But that's exactly the limitation.
Velocity tells you what already happened.
It doesn't tell you what's happening right now.
By the time your sprint velocity drops, the real problem probably started days earlier.
As an engineering manager, the questions you really care about are different.
-
Which issues have stopped moving?
-
Which stories are quietly waiting for someone to act?
-
Which commitments are likely to miss their target?
-
Which tickets need attention today?
Those are leading indicators.
And they're often invisible in Jira.
The Biggest Bottlenecks Rarely Look Like Blockers
Not every blocked issue is marked as blocked.
In fact, many never are.
Instead, they quietly sit in statuses like:
-
In Progress
-
Code Review
-
QA
-
Waiting for Customer
Nothing changes.
Nobody comments.
No one mentions them in standup.
From the dashboard, everything looks normal.
Until the deadline arrives.
One thing I've learned over the years is that software teams rarely struggle because people aren't working hard.
They struggle because work spends too much time waiting.
Waiting for reviews.
Waiting for approvals.
Waiting for clarification.
Waiting for another team.
Waiting becomes invisible.
And invisible work is difficult to manage.
Why Traditional Time-in-Status Reports Fall Short
A natural reaction is to start measuring how long issues remain in each workflow status.
That's a good idea.
Unfortunately, most implementations have important limitations.
1. Calendar Days Don't Reflect Reality
Imagine moving an issue into Code Review at 5 PM on Friday.
By Monday morning, many reports show the issue has been sitting there for almost three days.
But nobody worked during the weekend.
Those aren't three working days.
They're just three calendar days.
When metrics don't reflect reality, people stop trusting them.
2. Rework Gets Forgotten
Consider another situation.
An issue spends four days in Code Review.
A reviewer requests changes.
The issue returns to Development.
An hour later it's back in Code Review.
Many reports reset the timer.
Suddenly it looks like a brand new review.
But it isn't.
The team has actually spent more than four business days reviewing the same work.
That hidden effort disappears.
3. New Doesn't Mean Active
An issue moved into In Progress yesterday.
Looks healthy.
Except nobody has updated it.
No comments.
No commits.
No field changes.
The developer switched priorities after a production incident.
The issue isn't technically old.
But it has already stopped moving.
Most reports never tell you that.
4. Reports Arrive Too Late
Many engineering teams review delivery metrics weekly.
Some only look during retrospectives.
The problem is simple.
If a ticket has already been waiting for six days, discovering that fact in next week's report doesn't help today's sprint.
Good metrics should influence daily conversations.
Not monthly presentations.
What Engineering Managers Actually Need
Instead of asking
"How many story points did we finish?"
try asking
"Which work needs our attention today?"
That single shift changes the discussion.
Rather than measuring outputs after they're complete, you're monitoring work while it's still possible to improve the outcome.
That's where delivery becomes predictable.
Three Questions That Reveal Delivery Risk
Over time we found that most delivery problems can be detected by answering three simple questions.
Has this issue been waiting too long?
Not in calendar days.
In actual business days.
Is this commitment approaching its deadline?
Deadlines aren't the problem.
Surprises are.
Has anybody worked on it recently?
Sometimes silence is the strongest signal.
If any one of those answers becomes concerning, that issue deserves attention before it becomes tomorrow's escalation.
Bringing Flow Health Into Everyday Jira
This thinking eventually became StatusClock.
Instead of creating another dashboard that people forget to open, we wanted delivery health to appear where teams already work.
StatusClock adds real-time flow signals directly inside Jira.
Teams can immediately see:
-
How long work has remained in its current workflow stage
-
Total time spent in a stage, even if the issue left and returned later
-
Whether an issue has gone quiet
-
Whether a due date is approaching
-
Whether the issue needs attention
Everything is calculated using configurable business days rather than calendar days, so weekends and holidays don't distort the numbers.
Instead of asking developers to interpret reports, the important work naturally rises to the top.
Time in status along with Attention details shown on each Jira issue.
Flow Governance with attention issues
Easily create dashboards and default gadget
Custom JQL to search can be easily used in Jira automations
A Better Daily Standup
One unexpected outcome surprised us.
Teams didn't just use these metrics for reporting.
They changed how they ran standups.
Instead of everyone taking turns answering:
"What did you do yesterday?"
the conversation became:
"These three issues have stopped moving. What's preventing them from progressing?"
Those standups became shorter.
More focused.
And much more useful.
Because the discussion centred on removing blockers rather than reciting updates.
Small Signals Prevent Big Problems
Most delivery failures don't happen overnight.
They build slowly.
A review takes longer than expected.
An approval waits another day.
Someone changes priorities.
A dependency slips.
Individually these events seem harmless.
Together they become missed sprint goals.
Engineering managers don't need more reports.
They need earlier visibility.
The earlier a bottleneck is visible, the easier it is to fix.
Final Thoughts
Velocity still has an important place.
It helps explain what happened.
But if your goal is improving delivery predictability, reducing bottlenecks and helping teams focus on the work that actually needs attention, you need metrics that describe what's happening right now.
That's the philosophy behind StatusClock.
It wasn't built to replace Jira.
It was built to answer a simple question every engineering manager asks several times a day:
Which work needs my attention before it becomes tomorrow's problem?
I'd love to hear how your team monitors delivery health today.
Do you rely on velocity, dashboards, custom JQL, or something else?
Disclosure: I work on the team behind StatusClock, a Jira app focused on delivery health and workflow visibility. This article isn't about promoting the app. It's about a problem I've seen repeatedly across engineering teams and what we've learned while solving it.
Was this helpful?
Thanks!
MeghnaP_LogicLemur Labs
0 comments