Jira Agile Reports can quickly get overwhelming. Even with their new UI it’s still extremely complex, so no wonder so many people who are new to the tool struggle so much.
Jira for Scrum Masters can provide so much useful information that will make your life so much easier!
Let me show you five reports that you definitely should look into and how to read them with ease.
Ok, so here are the five reports that you need to know how to use:
- Sprint Report
- Velocity Chart
- Release Burndown
- Control Chart
- Epic Report
But in this blog, I want to dive into the Sprint Report because it can provide you with so much useful information to help you identify improvements the team may implement.
You will notice that I don’t go into details on the burndown chart that you will see at the very top of the Sprint report in Jira.
Jira tickets, what to do with them?
While this can be useful, I find that most teams do not go to the level of detail that those charts require. Most of the time teams work on the level of the tickets, and user stories in Jira, which take several days to complete.
But burndown and burnup charts are most useful when you break down your tickets into tasks that take about one day of work. Also the first report I’m going to talk about includes the burndown chart anyway.
So let’s look at the Sprint Report that can actually be a game changer for you.
Sprint Report Analysis
This is usually my go-to place at the end of the Sprint which helps me understand how the team is doing. And it can be very useful in preparation for a Sprint Review with your stakeholders.
We’ll skip the top part of the report since it’s a burndown and I generally don’t find them extremely useful. There are exceptions, of course, but let’s not get into the nitty-gritty here.
Once you scroll past the burndown you’ll start to see the info that we actually want: details on the tickets, user stories, bugs, etc. that the team worked on during the Sprint.
At the top here you’ll see the completed tickets.
When you are getting ready for your Sprint Review or maybe when you are collecting the information for a detailed Sprint Report you might be done separately, you can review this list and select the work items you actually want to show to your stakeholders.
If the team did a good job of naming the tickets, it will be even easier.
Because you can just screenshot this part of the report and show it in your Sprint Review to highlight all of the work that has been completed.
This report will also give you the number of completed story points if you are using estimation. But we’ll talk about it a bit later in the velocity chart part.
Jira Ticket: how to identify the Carry Over
Then you can scroll further to the Issues not Completed section.
This is where you can find all the info on the tickets that have been in the Sprint when it was closed but were not completed.
This basically shows the work that the team believed they could complete but wasn’t able to. This is your carryover.
Btw, if you are looking for some practical advice on how to deal with carryover I have a video about that.
Here you can also find the sum of the story points, not completed this time.
It can help you understand what percentage of work is actually carried over.
Just divide the not completed story points by the sum of completed and not completed points.
For example, here I have 41 completed points and 5 not completed. So I’ll do 5/(41+5) = 11%. It means that our carryover is 11%.
Agile teams and carryover management
Scrolling further you will see one more section called Issues Removed from Sprint. However, you will only see this section if there is anything that has been removed.
This can be a good indication of how well your team is planning. If there is a lot of work that is usually removed from a Sprint, it means that your team has a tendency to overcommit.
Or it may also mean that your priorities are constantly changing. More on this later.
Here you may be asking: why would we remove something from the Sprint and not just keep it until the end as a carryover?
Well, if it’s the middle of the Sprint and your team clearly looks at some tickets in the Sprint Backlog they haven’t started yet, and they know for sure they won’t be able to complete them, why keep those in your Sprint? Just remove them to keep your Sprint Backlog focused.
You shouldn’t keep your backlog set in stone – it will change and evolve as the team continues to work.
Measuring Scrum Team Performance Guide
This is a guide focused on helping you and your Scrum Team to collect appropriate Agile metrics for continuous improvement and working with management.
Jira Reports: changing ticket priorities
So what was that other thing I mentioned about changing priorities?
This is another important piece of information that the Sprint Report can provide you with, it’s just a bit hidden and may require some manual calculations.
When you look at the lists of Completed and Not completed issues you will see that some of them have a little asterisk next to their number. This means that this ticket has been added to the Sprint after it started.
If you have lots of tickets with an asterisk – that may be a problem, especially, if your team has a high percentage of carryover.
Unfortunately, Jira doesn’t calculate the numbers for you here, so you may need to pull out your calculator again and start summing up the story points for all of the tickets added.
Ok, we’ll need to do a bit of formula here to get some very important data.
First, sum up the completed and non-completed items on your sprint report – that will give you an idea of how much work the Sprint had when it was closed.
Then how much work the team committed to. This you can easily find in the Velocity chart. So go back to the reports tab and click on Velocity Chart, find the Sprint you’re analyzing on the graph, or in the table below, and take the number under Commitment.
This will show you how much work the team took into the Sprint initially when it was started. That’s an important number as it will help you identify the percentage of change your team is experiencing.
Jira Agile Reports: Calculating the Sprint Backlog
You can also do some math right in the Sprint report if you feel like it.
To do so, subtract the added tickets that you calculated earlier and add the removed tickets.
Now that you have the initial commitment, you’ll sum up your added and removed tickets and divide it by your initial commitment.
This will show you the % of your Sprint Backlog that has been changed.
Does that immediately mean bad bad things? No!
As I said earlier, Sprint Backlog is supposed to be changing.
But looking at your other stats it can help you understand if it IS indeed a problem.
I would say though that if your backlog changes by 50 or more percent, this is something you’d want to look into.
Sprint Backlog is not as bad as it seems
Say you have lots of items being added.
Why are they added? Is it because the other in-progress items got stuck somewhere and since developers couldn’t continue working on them, they decided to take something else into the Sprint?
Or is it because they genuinely were out of work, so they picked up something new from the Product Backlog?
Go into even more detail, checking how much work was added versus how much work was not completed. And you don’t need percentages for it.
For example, if the team has added 25 points into the Sprint, but has not completed 59, it means that they took on work on top of the backlog they already couldn’t accomplish.
If in addition to that, they haven’t removed as many tickets or maybe haven’t removed anything at all, it means that they are not replanning during the Sprint and are just taking on new tickets without considering how it may affect the rest of the Sprint Backlog.
This reminds me of that meme…
It is generally a good idea when you add a new item to your Sprint Backlog to remove something of a similar size.
What other useful information can you derive from the Sprint Report in Jira?
You can do a quick visual analysis of the work in the Not Completed list. Are there a lot of items that have been added that are sitting there? If yes, I’d ask the team why we are adding items when we already cannot complete what we committed to.
What about the Completed list? Are there lots of items that have been added and completed while the Not Completed list mostly has original tickets that have been added to the Sprint Backlog during the Sprint Planning?
If yes, then a good question to ask would be – why are we wasting our time in Planning on items that seem to be low priority, since in the end, we preferred to work on new items added?
And what if this is actually reversed? We completed lots of low-priority items that we added during the Sprint while lots of high-priority original items from the Sprint Planning have not been done. Why are we wasting our time working on low-priority items that we didn’t even plan for?
Jira Agile Reports can answer many questions
There are lots of questions that you can ask your team using the information provided by a single report!
A must-know point I want to make here, though, is that these numbers on their own do not represent the team’s performance and should not be used in that way.
If you want to learn more about that, check out my video on velocity.
Scrum Master expertise
Use the information you get from this report and all of those calculations to find what questions you can ask your team. Asking open powerful questions is how you can start coaching your team.
I think I’ll do a little deep dive into some powerful questions you can ask the team at the end of the Sprint into my upcoming newsletter.
So if you are not subscribed, definitely do so. It’s free. And we are over 4400 newsletter subs already! (the number keeps changing, so I keep updating it)
Let’s do a quick recap. In this video, we looked at how you can use the Jira Sprint Report:
- to collect valuable information about your team to help them improve.
- Get information on completed and not completed work; on issues removed from the Sprint and added to the Sprint; on the team’s velocity.
- But more importantly, it can give you insights into how your team can improve.
