Jira Metrics

Overview

On this page we’ll talk through the reports we find most valuable and how to read them; velocity, burnup, burndown, cumulative flow and control charts (cycle time).

Introduction

Agile is all about constantly reviewing to see if anything can be done better or more simply. This is often easier to do when you have some figures and statistics to refer to and see improve. There are many manual ways to do this, but here we’re going to talk about a tool we use most at Holiday Extras - Jira - and what it can offer in terms of reporting and metrics.

What Can I Measure in Jira?

There are loads of reports available in Jira - you'll find a link to these in your Jira project sidebar. Here's a run-through of some of the ones we find most valuable.

Velocity (Sprints)

“Track the amount of work completed from sprint to sprint. This helps you determine your team's velocity and estimate the work your team can realistically achieve in future sprints.”

Velocity chart with bar graphs for work committed to versus work completed

This is one of the simplest charts to read and is a quick win for a team to really think about how much work they’re pulling into a sprint. If you over-commit and under-deliver, stakeholders will be disappointed, there will be delays in getting value to customers and the team will be demoralised. The key is to be honest and realistic about what you can do and get that all done to a high standard before pulling in any other work. This chart only works with sprints and points.

In the above example, the team generally seem to pull in too much work so need to think carefully at planning to make sure they only commit to what they can actually achieve - it seems they run monthly sprints as well, so they may find that going to shorter cycles helps their delivery.

Burnup (Sprints)

“The Burnup Chart provides a visual representation of a sprint's completed work compared with its total scope. Track your team's progress towards sprint completion and identify problems related to scope creep.”

Example burnup chart showing scope, projection and actual achievement

This is a great visual chart which shows when you’re adding more work, what impact that has on your sprint. The grey line in the middle is the guideline for completing work at a regular cadence within a sprint (though we find this not really accurate for our teams). The red line is the work you agreed to at the start and this line should really stay as flat as possible. The green line is work completed and should slowly increase until it meets the red line at the end. This chart only works with sprints and points.

The example above shows that if the team had stuck to their original commitment (the original scope), they would have smashed their sprint, but because more was pulled in (scope creep), they didn’t quite get there. There will be factors, however, that contributed to this so this chart will only be part of the conversation in a retrospective to learn from and improve for next time.

Burndown (Sprints)

“Track the total work remaining and project the likelihood of achieving the sprint goal. This helps your team manage its progress and respond accordingly.”

Example burndown chart showing desired burndown against actual

This is very similar to a burnup chart and actually we think it’s less useful as it doesn’t show the scope creep. However, this can still be used to check you’re on track as a team to hit sprint if you want something more simple than the burnup. This chart only works with sprints and points.

In this example, half-way through they pulled in a lot more work despite not being on track with the grey average guideline in the middle which then resulted in them not quite hitting the sprint (though they did a great job considering how much extra was added).

Cumulative Flow (Kanban & Sprints)

“Shows the statuses of issues over time. This helps you identify potential bottlenecks that need to be investigated.”

Example cumulative flow diagram showing the number of issues in various status of development, e.g. In Progress

We love this chart! It looks incredibly confusing but it’s actually quite straightforward to read once you understand it. The first thing is that you need to click the “refine report’ drop down at the top and get rid of tickets in statuses like “To Do” or “Done” as this clogs up the report. You can also play with the dates until you get something more readable too. This chart works with sprints and kanban and doesn’t rely on points either.

What this chart does is to help show where the bottlenecks are in your team. Using the image above as an example, “In Code Review” seems to take up a lot of the overall time for this team. They could work on getting reviewers lined up early or breaking down their review process further. They could also limit their work in progress so focus on getting things through to completion.There are some times tickets appear to linger in “Test Ready” as well, so they could see if more tickets could be tested by others in the team if their dedicated Tester has a lot on.

Control Chart (Kanban and Sprints)

“Shows the cycle time for your product, version or sprint. This helps you identify whether data from the current process can be used to determine future performance.”

Example control chart showing cycle time for each task

This is probably the scariest looking chart Jira has to offer. It takes some time to learn how to read it, and Atlassian have a lot of guidance and support on reading your own charts. To simplify it as much as we can, the idea here is that you can get a view on how long it takes for an issue to be sorted, from being raised all the way through to being “Done” - your Cycle Time. Again, this chart can be tweaked in terms of timings, certain swimlanes or columns as well so is very customisable depending on what you’re trying to see. This chart works with sprints and kanban and doesn’t rely on points either.

This team are generally fairly efficient, though there are times tickets take them longer than anticipated. They could use this chart in a retro to discuss where the blue line goes above the red one to see if there’s anything they can learn from that. Product Owners can also use this to look at the individual issues that are outliers on this chart to understand why they aren’t being prioritised and either close them or get more information from stakeholders.

Sprint Report

These are available in the traditional style Jira and are really easy to use so we’re not going to go into huge detail on them here.

Dashboards

These can pull in a variety of information but are quite unique to each team so if you’d like one then chat to one of the Agile Coaches and we can help you see what’s possible and show you how they work.

Next Generation Projects

Jira are moving to Next Gen projects which have a lot of functionality but do have some limitations in terms of reporting. They generally have the charts we’ve mentioned above available, but a lot of the others we haven’t gone into detail are missing that many find invaluable. They also don’t have sprint reports in the same way. Some of these things will come in time, but if you need any of these now then it’s worth considering before starting a new project.

Summary

There are many more areas you can track than the ones we’ve mentioned, including time tracking and user workload if this is something you’re interested in, but we’ve found the above metrics the most useful in terms of seeing if changes to your processes and approaches is making a difference to the delivery of work.

The main thing to remember is that metrics are useful, but they don’t tell the whole story in terms of how a team is performing so we’d urge everyone not to just take metrics as a scorecard and instead to use this as part of the whole picture and for the teams themselves to see where they think they can improve further.

Further Resources

Report abuse