1. Home
  2. Training Library
  3. Business Management
  4. Courses
  5. Agile Reporting, the Jira Dashboard, and Jira Tools

Agile Reporting - Part Two

Developed with


Agile Reporting, Jira Dashboard, and Jira Tools

The course is part of this learning path

Agile Reporting - Part Two


This course takes a look at the different Agile reporting features provided by Jira. We'll cover burn-down charts, burn-up charts, velocity charts, version reports, epic reports, and Kanban reports.

We'll then move on to Jira dashboards and you will have the chance to follow along with a guided demonstration of how to build your own dashboards in Jira. You'll also look at some of the Jira tools available to manage your workflows and share information among your team.

If you have any feedback relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Learn about the various reporting features available in Jira
  • Learn about how to create dashboards in Jira
  • Learn about some of tools available in Jira to optimize your workflows

Intended Audience

Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of Agile practices. 


To get the most out of this course, you should have a basic understanding of Agile and Jira.


Now with the sample data, I can't show you all of the reports 'cause the data just isn't there but I can show you the version report. And this is quite nice, now remember a version is gonna be delivered over a number of sprints. And with the version report, it looks at the burn up rate. So how quickly are we delivering story points? What's the rate at which we're delivering story points?

So it's looking at that burn up rate. And then it's looking at our release date. So that is our release date, and then it's projecting forward from our burn up rate, it's projecting forward when it thinks we're going to actually deliver everything in the version. So in other words, all of the story points in the version. There's our release date for our version, and those are actual projection. That's the predicted completion date. And it gives us an estimate. It gives us an optimistic and a pessimistic view of that. So that's quite useful report as well. And you can certainly use that to sort of view how, based on how the project is going, how likely it is you're gonna hit those version targets.

We can do things like Epic reports, we can look at Epic burn downs and release burn downs as well, to work out how many sprints it would take to deliver an Epic or a release. But these reports all help us, I haven't got enough data to show you either those two reports, but yeah, I don't think there is enough now that there isn't, I don't think that there is for those reports. So sometimes generating the right data for these is quite difficult. But what I can do, I'll show you the, my Kanban project, because there are a couple of reports on that, that get really useful for Kanban.

Now, if you're doing Kanban you'll want to look at the control chart and the cumulative flow diagram in Kanban. Those are two really useful Kanban reports. You can look at them in Scrum but they're incredibly useful for Kanban, right? So the control chart, and I'm gonna need to change the timeframe on the control, to make it to past week.

Now the control chart works best when the tasks that you're tracking are supposed to be of the similar size. And if they are predicted to be the similar size then this technique works really well. You can limit them to the columns that they're coming from and also the swim lanes. So you could sort of tailor it. So, you know, when you're looking at certain swim lanes to make the analysis easier to do, but it's wildly different in terms of the usual duration, then the technique I'm about to show you doesn't then work. Because what we're trying to do is we're trying to look at a process where it should take a certain length of time consistently to get from the beginning to the end.

So if you imagine producing a car or a chair or fixing a printer should take a certain length of time. And if it doesn't, then this, you know, we need to ask what's going on. And so what we do is we look at how long it's taken for these issues to be resolved. And then on the control chart is looking at the cycle time, the time taken to get from in progress to done, or in fact you can control what's gonna be involved, so which steps in your value stream are involved. And the blue line is the rolling average cycle time. And then the light blue line is standard deviation. So that's the variability of the average. 

So how consistent we've been in terms of how long we're taking to complete our task. And then the green dots are the issues themselves. The control chart technique involves looking for the outliers that are above the line. Now it doesn't look as though we're too bad here, so above the line that you could possibly say that one is an outlier. If it's above the standard deviation line, we could maybe click on it and get some more detail. And this is where we're potentially looking for adaptations. This is where we are on our money. And we might say, "Why did that take the time that it took? "Can we change our ordering or supply chain "or training, or what is it we can change to stop "that taking the time that it's taken? "Why did it take that time?" in other words. And then any improvements we can put in place will then hopefully over time narrow the standard deviation line, and bring the blue line average down in our charts because we're reducing the cycle time over time.

So that would be how you might use the control chart. So there are a few caveats in that, but it certainly, what I was saying at the beginning, in protocol process control, where you're using the data, the fact that we know when it starts and we know when it finishes to then use that data to ask the questions necessary to maybe put in place adaptation and there's JIRA, that's the role that it plays in agile. And then the other one is the cumulative flow diagram. And what we're seeing with the cumulative flow diagram are the number of issues in each of the states.

So in our backlog, selected for development. So the interface between the two is leaving and entering the next state, and then horizontal line from the entering to the leaving would be the cycle time between those two states, between those states. So you can visually sorts of work it out from there. And really what we're looking to do is kind of have, it's almost like a kind of a spongecake, you ideally want even layers, while you've got a nice slow moving between the states and this green layer is completed.

So this is going to be building up over time, so that, but if you've got either layers through here, then things are progressing in parallel which is quite a nice situation to be in. But if you see narrowing, you see a sort of narrowing, there is a sort of narrowing going on there, there's potentially a throughput issue happening. And it means that the throughput at this stage is higher than the entry rate, and so you might want to look at optimizing the flow at that stage, when you get that narrowing.

If you get widening, so if the bands are widening, so if this was widening, and this was widening as well, that's usually caused by multitasking. So if you see one band widening, and the other band widening at the same point, then that's also usually an indicator of multitasking. So the cumulative flow diagram can kind of, can show you just by the sort of layers, it can show you various issues that are hidden inside. I mean, the control flow diagram, your Kanban chart, they can all share the same kinds of things, but it's quite a nice kind of summary almost of what's going on within your process.

So narrowing or widening can be indicators that you need more analysis in the flow of your issues. So another really good diagram to look at.

About the Author
Learning paths29

QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.