In Agile, speed is a tricky word.
Some teams equate it with how fast they close issues. Others treat it as “velocity” in the Scrum sense: completed story points per sprint.
The truth is: speed is multi-dimensional. And Jira gives us just enough raw data to get lost in it.
After working with dozens of teams from small startups to enterprise PMOs I’ve seen the same thing: two teams can have the same velocity but radically different delivery realities.
Let’s walk through five practical ways to measure speed in Jira, using three familiar metrics: Velocity, Burndown, and Burnup.
Velocity is a great planning tool… until it isn’t.
Take Team Alpha, a 7-person Scrum team in a fintech company. Their velocity chart showed an average of 36 story points per sprint for the last three months. Solid, right?
But zoom in: in the last four sprints, they went 28 → 42 → 31 → 43. That’s a ±20% fluctuation enough to cause missed release dates.
How to track stability in Jira:
Use the built-in Velocity chart under Reports.
Export the last 6–8 sprints to a spreadsheet.
Calculate the standard deviation of velocity — aim for ≤15%.
Tip: A stable velocity is often a better predictor for delivery confidence than a high one.
Team Beta, an Atlassian Marketplace partner, had a classic burndown problem:
By day 5 of their 10-day sprint, they had burned just 5 points. But instead of a steady decline, the burndown chart flattened, and even climbed mid-sprint. Why? New “must-have” issues kept getting added.
How to spot it early:
In Jira’s Burndown Chart, look for sudden upward jumps they mean scope has increased.
Call it out in daily stand-ups: “We’ve added X story points since Monday what’s the impact?”
Tip: Don’t confuse slow burn with scope creep. If the slope is flat but scope hasn’t changed, it’s a delivery pace issue, not a planning one.
Burnup charts are underrated.
Team Gamma, a distributed dev team in Germany and Poland, switched to Burnup after constant burndown confusion.
Their revelation:
While their “Completed work” line grew steadily, the “Total scope” line also kept climbing. This visual made it obvious to stakeholders that the team was working fine the goalposts were moving.
In Jira:
Native Burnup is available in Advanced Roadmaps.
Or use an add-on that generates Burnup from sprint data.
Watch for the gap between “Total scope” and “Completed” a widening gap means you’re chasing a moving target.
Velocity tells you how much. Cycle time tells you how fast individual items move.
Team Delta had a velocity of 40 points per sprint, but their average cycle time for medium-sized issues was 12 days. That’s too long for a 2-week sprint.
In Jira:
Use the Control Chart to get cycle time.
Cross-reference it with your velocity chart: high velocity + long cycle time might mean you’re closing many small issues but struggling with big ones.
If you need per-issue cycle time inside the sprint, some marketplace apps (like Sprint Health Analyzer) calculate it from changelogs and group by risk level.
Sometimes speed hides fragility.
Team Epsilon closed sprints on time but a closer look showed:
40% of time in “Blocked” status.
Frequent backward jumps (“In Review” → “In Progress”).
Heavy dependency links.
When they started tracking a health score alongside velocity, they noticed patterns: spikes in blocked time → dips in velocity 1–2 sprints later.
In Jira:
Use issue filters to measure time in Blocked statuses.
Track status jumps to see workflow churn.
Tools like Sprint Health Analyzer bundle these into a single health score and group issues by risk level, so you see why speed is dropping before it’s visible in velocity.
Velocity, Burndown, and Burnup are simple on paper but in practice, they’re lenses on different realities:
Velocity: Are we delivering at a consistent pace?
Burndown: Are we burning scope as planned?
Burnup: Is the target moving?
Cycle Time: How fast do items really move?
Health Metrics: Are we delivering sustainably?
If you only check one chart, you’ll miss the story.
Whether you use Jira’s built-in reports or a marketplace app like Sprint Health Analyzer to pull it all together, the goal is the same: make speed predictable and sustainable.
Maksym Babenko_TypeSwitch_
0 comments