Agile Reporting - Part One
Intro to Agile
Jira and Agile
Jira Dashboard and Tools
Conclusion and Q&A
The course is part of these learning paths
This course is designed for users who are already able to create, update and search for issues in Jira but now want to understand how to use Jira to control, manage, and maximize the effectiveness of their agile projects. We will look at using Jira in Scrum and Kanban projects and how Jira can be a powerful aid in the pursuit of empirical process control.
If you have any feedback relating to this course, feel free to contact us at firstname.lastname@example.org.
- Review Agile, Scrum, and Kanban practices and how Jira can be used in conjunction with them
- Understand how Jira can be used to capture Epics, Stories, Tasks, and Acceptance Criteria
- Understand how to use Jira to manage Scrum and Kanban projects
- Learn how to use the Jira dashboard and tools
Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of agile practices.
To get those most out of this course, you should have a basic understanding of agile and Jira.
What I'll do then, is, I'm going to show you, the section on Agile reporting. We're gonna look at Agile reporting next. We'll look at some of the different agile reports that are available in Jira. 'Cause remember we were just talking about Jira, and the reason that we use it.
Jira is a tool, and agile encourages us to have interactions with the relevant people within the organization. We want to be able to do that rather than just rely on tools. Why tools become useful, is really what's relevant in this chapter. Because the ability to run reports and even look at dashboards, is where we can get the insight that we need while we're doing our inspection, to enable us to achieve adaptation, while we get empirical process control.
Entering information into Jira, gives us the data that we need, to allow us to inspect and then adapt. That's why Jira is useful. Not because it's replacing the need for us to talk and interact. Let's have a look at the kind of reporting that we can do.
In order to do that, I need to create a couple more projects with sample data. My scrum project. I need to create one in here as well. Everybody will have access to my scrum project. If you go to projects and then, view all projects, you should see my scrum project. So that's project, view all projects, you should see my scrum project. Right. So my scrum project, has a filled in backlog and you can see we've got some sprints that have been completed, and we've got a backlog.
We've got a sprint that's already active and actually, there are a couple of other sprints as well that are completed. We look at the active sprints. That's our active sprint. If I go down a little bit farther, you can see that there's an icon that looks a bit like a graph. Well, there is a graph. Isn't that? This is our reports icon. This is where we can start doing the inspection so that we can adapt. And because this is a scrum project, I can start looking at some important charts. One of them is the burn down chart.
Anyone come across a burn down chart before? You use burn down charts? I've seen it in Azure DevOps, 'cause it's always displayed at the top of the sprint and-- Yeah yeah. So a burn down chart, if I bring this up now, here's my burn down chart. Let's run it. I'm gonna get rid of non-working days, 'cause the gray is the non-working days. I'll just click on the tick there so we get rid of that. The burn down chart is displaying the information in terms of the story points or the estimated amount of time this sprint was gonna take to deliver.
We're looking at sample sprint 2. And sample sprint 2, was estimated at, the way it looks like 13 story point, sorry, 11 story points. In total, all of the user stories, were estimated to be in total 11 story points. It was a two week sprint. The gray line is showing in a perfect world, 11 story points would be delivered in two weeks. That's why you see that gray line. That's the perfect world scenario. The red line is showing what was actually delivered.
So you can see as we're going along, no stories have been delivered but the developers have been working on the sub-tasks. So sub-tasks are being completed. When the last sub-task gets completed, all of the story points for that story, are then subtracted, and we get to here. When we're above the line, we're theoretically a bit behind, but when we're below the line, we're theoretically a bit ahead. We're not really... just depends where we are with our sub-tasks. And those just here, what do you think happened? How can we get backwards? I don't know something to do with sprints. Yeah. It's a scope change. That was a question we had earlier on.
We can add new things to the sprint. It's not ideal, but it does happen. It's a scope change. We didn't quite make it here. Did we? Let's have a look at sample sprint 1. What sample sprint 1 telling me, that's where I should have been. That's where I am. What's it telling me? Well, the fact that we get to the end of the sprint, and we're still above the line, means that we didn't deliver everything. Was still a couple of story points short, was short by two story points. We didn't deliver one of the stories. We said we could deliver, in this case, we said we could deliver 18 story points and we actually delivered 16 by look of it. We under delivered in that case. If we'd been below the line, then we would have delivered what we said we were going to.
So the burn down chart gives us a rough progress of where we are. Switch report, go to all the reports, and you'll get back up. We often use the sprint report when we were going into daily scrums. It will give a bit more detail. It gives you your burn down chart and also a bit more detail. Burnup chart as well, sort of a little bit similar to the burn down chart. It kind of gives you a bit more analysis of scope change. You can see in green, we can see the completed work, as it's going along, the gray line again is the ideal world. It gives you a little bit... that's the guideline. That's the work scope. It's sort of a slightly different view of the same kind of chart.
A really useful report to look at is the velocity chart. It's a bit more useful, to be honest when you have more completed sprints. But you can see sample sprint 1, we said that we were gonna deliver 18 story points and we only delivered 16, and it's showing us the average. Now, if we have more sprints, we'll be able to see more clearly what our average story point delivery was. This would help us in estimating what we would be able to deliver going forward.
As our estimating got better, this'll become more and more accurate. I mean, just with one it's not particularly useful but we could certainly see when we're going over and we can start to get an idea as what typically we're able to deliver. That's a really useful tool. It's a really useful report particularly when we have a little bit of data behind us.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.