What Metrics Should You Track in Jira?
7 Measurements for Better Decision-Making
You can't manage what you can't measure – and this is certainly true of work in Jira. The platform holds tremendous capabilities to capture and analyze data, but first, you need to have a strong sense of what is useful for generating valuable insights, and how to gather that information correctly.
Many organizations already focus on metrics such as cost and hours worked – rightly so! – and there's a lot to discuss with regard to *how* to measure those things well.
But this article is about less-common metrics that can add valuable nuance to standard project management metrics. We want to suggest our favorite metrics, based on our experience with organizations like yours.
These figures can help you make better decisions: How on track are you, really? How can you improve your processes? And the big one: Is this project worth pursuing, or should you stop throwing good time after bad?
In no particular order, a list of our favorite metrics, and some tips for how and where to measure them:
Work in progress (WIP)
What you get from it: Understand where bottlenecks are cropping up
Measuring how much work is currently underway gives insights into which issues are stuck and which teams may be struggling to overcome unexpected challenges.
- Review the number of stories or tasks in the "In Progress" status category – whether by project, team, or overall. You can view this as a single number of items that are WIP, and you can visualize it in a graph such as a Cumulative Flow Diagram – in CFD, the work-in-progress issues should look like a thin layer on top of the Done area. If it bunches up, you should investigate.
- Chart the average time a story is in the "In Progress" status category. Tracking the mean and standard deviations of this helps you spot issues of concern early, so you can take action.
Where to track: All levels of your issue hierarchy
Business priority or value
What you get from it: Understand what to prioritize, and whether or not the project is worth the amount of time you're spending on it.
How to track:
- Business values must be placed on a predetermined, fixed grouping or scale (1-10, or 1-4, for example), so teams actually understand what is the highest priority.
- Depending on your situation, you may want to decompose business value down into several values from various elements of the business (especially when you need to balance multiple internal stakeholders like Sales, Marketing, etc).
Where to track: Per epic/feature
Novelty/repeatability
What you get from it: Create better and more reliable work estimates by measuring how new a particular work item is to a team. For example, if they've done something dozens of times before, they can put reliable estimates on that item. But if it's fairly novel to them, those estimates are far more variable – a useful factor to consider for planning.
How to track: It's important to use this measurement correctly alongside other estimation parameters. Create your own measurements of novelty vs. repeatability by building a scale (again, perhaps a 1-4 scale, from most repetitive to most novel) and adding those numbers to your typical estimate.
Where to track: Per work item (i.e., story or task)
Lead time
What you get from it: By tracking the time between the request for a feature or epic and its completion, you can perform process-based retrospectives. Find gaps in hand-offs, teams that are overloaded, poor communication, and other hidden snags that hinder teams from getting work started.
How to track: Monitor the number of days between requests and their completion, per team – you can look at only features and epics, or add nuance by tracking subcomponents to get a fine-grained look at your development process.
Where to track: Per epic if your team is decomposing the work, but can be per ticket if you have a service desk or individual task-submission process.
Cycle time
What you get from it: This is the measure of how long it takes items to go from "in progress" to "complete." It's useful as part of the Kanban philosophy of limiting WIP. Note that this is different from lead time, which deals with when work gets started – cycle time is about how long in-progress work requires before it is done.
How to track: Calculate dynamically in Jira, where these transitions can be recorded accurately, and you can dig in for additional nuance based on different cycle times for different projects. Is the cycle time for bugs different than for feature work? How does the standard deviation change when you include time in testing vs solely development work? When you track in Jira, you can keep objective measurements and zero in on specific areas of concern.
Where to track: Per epic or per team – similar to lead time.
Weighted Shortest Job First (WSJF), or similar metrics
What you get from it: The ability to sequence upcoming work based on what will give the greatest economic benefit for the least effort. It's a general "bang for your buck" score. How much value does each action provide your organization? Knowing this can help you prioritize your backlog – especially valuable if you have some remaining capacity to do additional work, and you need to figure out what would be most valuable.
How to track: Put simply, WSJF is the cost of delay divided by job duration. Actually arriving at those numbers is a bit more involved, as you can imagine – the Scaled Agile Framework (SAFe®) explanation is a good place to go for newcomers to the concept. Typically, it's the cost metric divided by all possible impact scores – usually the weighted ratio of points given to a task per stakeholder.
Where to track: Epic/feature (estimation level)
Net Promoter Score or other external review metrics
What you get from it: Companies often survey NPS or other similar metrics for their released products to get immediate customer response and better understand how well-received a feature or product is – or to track trends, such as whether your investments in customer service have actually led to happier customers.
How to track it: Most companies survey products at the moment that product is released – but it's important to remember that those quick reactions are somewhat limited. Complex features haven’t had time to prove themselves, and longer-term issues and impacts such as stability increases or decreases don’t surface until later. Just like with any information derived from surveys or subjective measures, take the results with a grain of salt as well as be very mindful of the context in which it was asked and answered.
Where to track: Anywhere from support tickets to whole products.
Have questions? Want to share your favorite metrics? Leave a comment!
Many thanks to my colleague @Philip Heijkoop _ALM Works_, whose ideas formed the basis for this post.
Was this helpful?
Thanks!
Dave Rosenlund
About this author
Atlassian (Online) Community Leader
Boston
89 accepted answers
5 comments