In the software industry, we all have to, at some point or another, deal with JIRA. The “glorified to-do list” has the power to strike fear into the heart of even the most hardened dev, but can also be a source of great satisfaction when it is used correctly. Problem is, nobody really knows how to use it correctly.
There is a certain infuriating complexity to the JIRA interface which makes attaining proficiency with it a brutal, unforgiving task.
I have endured JIRA since 2015 and I have never had the pleasure of working with a team who was leveraging the tool to correctly visualize progress. Up until now, I would do what most people are doing with JIRA, update my ticket status, hunker down during the sprint grooming sessions, spew out Fibonacci numbers during story pointing and glanced at the active sprint board occasionally to make sure the tasks underneath my name didn’t make me look bad.
Not anymore! I decided to spend some time investigating the secret JIRA magic. I know that not only is JIRA an awesome ledger of development activity, but it also has a reporting component which I felt could provide some much needed insights into the health of the project. In other words, I was intrigued by the capability of JIRA to conduct process improvement.
So here we go, here are my preliminary findings with regards to improving our understanding of JIRA.
At its most basic, JIRA is a ticket tracking system. Users create tickets and those tickets are queryable and can be rendered in different formats (lists, boards, graphs). The problem is that the classification vectors (the predicates according to which the lists can be organized) are way too numerous for someone to have a clear understanding of how our changes in JIRA affect the reported metrics and whether anybody, for that matter, is even looking at those metrics. This article is my attempt to clarify what some of those metrics are, and how to interpret them.
The vectors I am referring to are for example:
- Fixed version
How is one expected to have any sense of control when he is asked to populate so many fields without any explanation.
The truth is that most of these fields can be omitted, at least during the time it takes to understand how JIRA works in its most basic form. In its most basic form, the only thing JIRA cares about is amount of story points consumed over time, which is called velocity.
JIRA also needs some kind of property against which to produce a total number of story points to be used as the target against which to apply the velocity calculations to make projections about completion date. That property is, in the most basic scenario, a release.
It all starts with a backlog!
Before we even delve into allocating work towards a particular delivery (the release), let’s first use JIRA without any particular delivery in mind, simply as a repository to store a list of things to do. This is the function of the backlog. The backlog is where newly created items will go in anticipation of being prioritized, pointed, targeted towards a release and scheduled for development as part of a sprint.
The items in JIRA come in three primary flavors:
For the sake of this example we will use nothing but stories, but the result is the same for the other two types.
Let’s get our hands dirty!
Go to JIRA > Projects > Create Project > Classic Project
Select template of type SCRUM and give it a name.
You will be taken to the landing page for you project. You will notice a navigation pane on the left and a detail pane in the center. The backlog tab will most likely be preselected.
The Backlog view
This is the main view to manage content in JIRA. Here you will see all your JIRA tickets. If no sprint has been loaded and started (we’ll talk about sprints later), all new items will go into the backlog. The Backlog is a convenient place to browse all the work that has been entered in JIRA in the form of JIRA stories / tasks or bugs and prioritize them by bringing the high priority items up top.
The backlog view allows to drill into the list according to two major differentiators: Release and Epic. Those filters can be found on the left side of the backlog detail pane
- Releases are the most important vector in the JIRA project. With it will be tagged all items which are slated to be shipped at a point in time.
- Epics are a second vector of classification which represent standalone features which may or may not be synchronized with releases, but against which projections can also be made. We will only focus on releases for now.
Loading the backlog
Here we are with no particular delivery in mind, just listing all the things that need to be done. Let’s create a dozen JIRA stories.
Select the plus button and create a new story. Enter nothing but Summary (and description if desired). Click Create.
Watch the list grow in the backlog view.
Once we are satisfied with our list, let’s prioritize it by drag and dropping items closer to the top or bottom based on their priority. The result should look something like this:
The next step in the JIRA workflow is to go over every item in the backlog and give it an estimated number of story points.
A whole chapter could be dedicated to the art of pointing. In a nutshell the number of points for a given task is supposed to represent “complexity”. Don’t let an agile aficionado catch you saying that the points represent time, or even worst that points represent days, they will crucify you, and have minor a heart attack. Nobody bothered to tell them that complexity and time are positively correlated (agile people are very picky about words and about feeling which words elicit, that’s part of their manifesto…)
Since these are rough estimates and not precise estimates, we use the Fibonacci scale to point things, 0, 1, 2, 3, 5, 8, 13, 21, 34… There is no need to be extra precise about stuff that would take more than a couple of days to complete.
Points are a double edged sword, they are used as currency in the calculation of projections, but they are also under constant pressure to be re-evaluated in case the estimate does not meet the outcome (in which case the question should be asked: did we miss our estimate because we slacked off, or because we underestimated the complexity). As such becoming good at pointing things is a continuous process and the accuracy of the estimates should be expected to improve over time.
Let’s go ahead and estimate all our stories in the backlog by giving them a number of story points according to their complexity.
For each existing story, find the story points field and populate it with a number from the Fibonacci sequence according to its perceived complexity. If the Story Points field is missing, it needs to be re-added. This can be done from Configure fields > Where is my field, or at Jira Settings > Issues > Screens (note, the configurations of screen fields is a ridiculously complicated process that involves screen schemes which are specific to the project and I will delve into those in a separate tutorial).
The result should look like this in the backlog view, with all the stories pointed:
Unleash the reporting functions of JIRA with a release
Creating a release
Now that we have a backlog of prioritized, pointed stories, we can start planning for delivery in the form of a release.
A release is the simplest, most important vector according to which to organize records in JIRA. It’s basically a hypothetical date in the future by which you ambition to deliver some value to a customer (could be yourself). You can name your release whatever you like, does not need to have a version number, could be something as simple as “working prototype”. There, that’s your release. All that follows, and the value added by JIRA, has to do with making progress towards that goal quantifiable.
In other words, creating and loading a release is the easiest way to see those fancy JIRA reports in action.
So the name of the game is:
- To create a release
- To load it with pointed items.
Go to the Releases tab and Select “Create Version”. Give it any name and any date.
A word on reports
JIRA offers a selection of reports out of the box. In this tutorial, we will only focus on the following:
The version report
- JIRA official description: “Track the projected release date for a version. This helps you monitor whether the version will release on time, so you can take action if work is falling behind.”
- We will use it for: general overview of the rate at which work is completed, volume of work remaining as it relates to volume of completed work, projections about the release date. Visualize consequences of scope change.
- Needs: At least one release. Needs ten percent of work completed to display projections.
The burndown chart
- JIRA official description: “Track the total work remaining and project the likelihood of achieving the sprint goal. This helps your team manage its progress and respond accordingly.”
- We will use it for: A more granular (zoomed in) snapshot of our progress, it will basically tell us that:
- If we have reasonably loaded the sprint (at the level of our current calculated velocity)
- If we meet our commitment for the sprint
- We will not negatively impact our release date.
- Needs: At least one sprint.
The release burndown
- JIRA official description: “Track the projected release date for a version (optimized for Scrum). This helps you monitor whether the version will release on time, so you can take action if work is falling behind.”
- We will use it for: Assess our progress in terms of sprints, and find out how many more sprints we’ll need to ship the release. Visualize consequences of scope change.
- Needs: At least one release. Needs three completed sprints to display projections.
Load the release
Now that we have a release available, let’s go over the prioritized, pointed backlog and load the release with some, but not all, of the items listed.
Go ahead and pick those items in the backlog which have the highest priority and edit each of them to target your newly created release by modifying the “Fixed in” field.
The end result should look something like this (I did a small release of 12 points spread across 5 stories).
Start tracking progress
We will start with the version report.
This graph plots:
- Story points on the y axis, and maxes out at the total amount of points included in a release (the sum of all the pointed items which are targeted for that release).
- Time on the x axis.
If you navigate to the version report right now, you will witness the grey line climbing up all the way to max Y in a stairs pattern. This is what “loading the release” looks like.
Every time you close an item, the blue line will tick up by the amounts of points of that item (this is called a burnup). Go ahead and mark a story in your release Done, and come back to the version report, you should see the following:
What’s more, once you have closed 10% of the work allocated for that release, the x-axis will open up drastically to reveal your expected completion date! Lets close more stories until we have completed 10% of the release in story points and you should be able to see the following:
From here, it’s easy to understand how this graph can provide valuable information with regards to the status of an upcoming release. For example think about what the graph would look like under the following scenarios:
- More issues are added to the release (the max y would increase, making the intersection of the velocity line and the max y shift to the right and pushing the predicted completion date further into the future).
- Issues are removed from the release (the max y would decrease, shifting the intersection of the velocity line with the max y to the left and bringing the predicted completion date closer).
- The velocity drops (the velocity line flattens, shifting its intersection with the max y to the right, pushing the predicted completion date further out).
- The velocity increases (the velocity line steepens, shifting its intersection with the max y shift to the left and bringing the predicted completion date closer).
- An issue is re-opened (the velocity line flattens, shifting its intersection with the max y to the right, pushing the predicted completion date further out).
Here is a somewhat mature version report with some use cases illustrated:
Quantify progress better with sprints
In SCRUM, we like to use another layer of abstraction to plan work and track progress: meet the sprint! A sprint is nothing more than a commitment to accomplish a certain volume of work within a given time period. The system works best if it is repeated on a recurrent interval, therefore a sprint will usually be of a fixed duration (2 weeks for example), and they will run contiguous to each other with no downtime in between sprints. That way all work is completed within a sprint, and we can start tracking velocity at the sprint level, and make estimates in terms of remaining number of sprints.
Sprints achieve much more than just tracking progress:
- Because sprints are usually loaded from one to the next (the upcoming sprint will be loaded around the end of the active sprint, in an exercise called sprint grooming), they do not compromise the flexibility which is so dear to agile. If something comes up and the team needs to re-rout resources in a strange new direction on short notice, the next sprint can be re-purposed accordingly. They are a blank slates which come up on a regular interval against which to schedule the work which is of highest priority at that time.
- Sprints allow us to make incremental short term commitments against which we can hold ourselves accountable.
- Sprints become the heartbeat of the development lifecycle, and they provide a detailed snapshot of who is working on what at any point in time, increasing the visibility of incoming changes and reducing the risk of collisions or misunderstandings.
Create and load you first sprint
For the purpose of this exercise we’ll make sprints of very short duration so that we can demonstrate what happens after three sprints are closed in terms of projections, but keep in mind that usually sprints span multiple days.
Go to the backlog view and click the “Create sprint” button.
This will cause the sprint area to be displayed right above the backlog for you to load by dragging and dropping items from the backlog.
If you wish to change the name you can click on the three dots on the right of your new sprint and select “”Edit Sprint”.
Now let’s load the Sprint. This would usually happen with the whole development team, towards the end of the outgoing sprint. The scrum master will go over the status of the outgoing sprint and look for any issues which will carryover, and then load the rest of the capacity with stuff from the prioritized backlog. Loading a sprint is not an exact science, but in a perfect world you want the total points for the sprint not to exceed your normal sprint velocity. In a perfect world you also don’t want anything to carry over from the previous sprint, because that would mean that you failed to meet your commitment, and it will push the release date back. We’ll get to what that looks like in a moment when we look at the Release Burndown report. We don’t have any knowledge of our sprint velocity at this point because this is our first sprint. Our performance with this very first sprint will give us a baseline sprint velocity, so we’ll be better informed about what our “sprint capacity” is when we load the second sprint.
Let’s go ahead and load the sprint with stories targeted towards the release. Putting items in the sprint which are not targeted for a release will not reflect upon the release burndown, so let’s have an ample pool of release stories to draw from. I have forty points worth of stories slated for my release as follows:
I’ll load my sprint with 8 points, the first two stories which are supposedly of the highest priority. Sprint is loaded, click “Start Sprint”.
Arguably the most important attributes of the Sprint are the start and end date. The start and end date are critical to the sprint because that is what is going to define the x axis and the x coordinate of the burndown line in the burndown chart. For the sake of the exercise I am going to make this sprint one hour long, so that we can witness changes to the burndown chart in real time, but in a realistic scenario the duration would be a week or two, depending on the team.
This will take you to the Active Sprint board. From there you can drag cards across columns to change their status. But before you mark anything “Closed”. Let’s take a peak at the burndown chart.
Tracking sprint progress with the burndown chart
Go to reports > Burndown Chart. You will a graph with the following:
- Total story points for the sprint plotted on the y axis.
- Time plotted on the x axis
- A red line indicating amount of story points remaining at a point in time.
- A grey guideline which represents your target burndown. In a perfect world this is where the red line should be.
- Below the graph you will see a table which lists all changes which have affected the graph since the sprint started
If, like me, you have configured the sprint to be one hour long, you will be able to notice the red line moving to the right if you hit refresh. The line is flat, which is normal, since we are not marking any stories “Done”. We are not burning down.
Let’s witness what happens when you mark one story from the sprint “Done”. Go to the Active Sprint Board and drag one card to the Done column.
The burndown ticked down! We are now under the target, which is where we like to be.
You get the idea. The name of the game is to bring the red line all the way down to zero on the y axis before time runs out.
There is a ton of interesting deductions to be made from the shape of the burndown:
- Red line did not reach zero before the end of the sprint: either the team misestimated, or the team did not work fast enough. Either way the release date will be compromised.
- Red line reached zero early: either the estimates were too light, or the team is gaining speed, they can take on more story points per sprint. More items from the backlog should be loaded into the current sprint. The release date will be moved forward, or more can be shipped with this release.
- The red line ticks up? Either somebody added something to the sprint after it was started (scope change), or an issue that was marked closed was re-opened.
But ultimately the burndown provides the following key insights:
- If we loaded the sprint according to our normal velocity, and we fulfilled our commitment for the sprint, we are on track to meet the release date.
- If we are meeting our commitment early, it could be because we are working better and faster, let’s look into what we did right and try to do more of it.
- If we are not meeting our commitment, something could be affecting productivity in the team, let’s investigate what that is and resolve it (a bottleneck in the code reviews? Missing access rights? Architectural stalemate?).
Tracking release burndown with Sprints
Let’s close the remaining items for our first Sprint and close the Sprint. Go to the Active Sprint screen and click “Complete Sprint”.
This should give you a nice Sprint report with the burndown. Mine looks like this:
Now let’s navigate to the Release Burndown report. This chart is a bar chart with the following attributes:
- Total story points for the release as the y axis.
- Individual sprints as the x axis, showing any burndown and scope change at the sprint level
- Once three sprints are completed, the report will use a calculated sprint velocity to etch the forecasted remaining sprints for this release.
As indicated, the chart does not calculate sprint velocity or forecast unless we close three sprints. Let’s go ahead and load, start, and complete two additional sprints.
2 sprints later…
This graph offers the same insight as the version report, but on a sprint basis. Since SCRUM teams use the sprint as their work currency, it is sometimes more telling to look at the status of a release in terms of sprints, but the dynamics remain the same. Note: the duration of the sprint, and whether sprints have consistent durations has no effect on this report. The only thing that matters is the average sprint velocity.
Lets look at what various contingencies look like on the release burndown:
- Issues are added to the release: The total points for the release increase, with velocity remaining unchanged, the forecast will potentially need additional sprints to bring the total story points to zero.
- Issues are removed from the release: The total points for the release decrease, with velocity remaining unchanged, the forecast will potentially need less sprints to bring the total story points to zero.
- Sprint velocity drops (because a new completed sprint did not meet its commitment): the average sprint velocity will drop, and the forecast will potentially need additional sprints to bring the total story points to zero.
- Sprint velocity increases (because a new completed sprint has closed more story points than usual): the average sprint velocity will increase, and the forecast will potentially need less sprints to bring the total story points to zero.
- An issue gets re-opened: The burndown for the affected sprint will drop and the total remaining story points for the release will increase, the current average velocity will drop and the forecast will potentially need additional sprints to bring the total story points to zero.
- An issue gets closed outside of a sprint: The burndown will be reflected in the latest completed sprint, the forecast will potentially need less sprints to bring the total story points to zero.
If you have soldiered through this entire tutorial, you now understand the fundamentals of JIRA, namely story points targeted towards a release, velocity and burndown. There are a lot more bells and whistles to JIRA. JIRA administration alone is massive topic. Let’s not mention all the customization points such as ticket lifecycle (called workflows). There are also some more visible concepts of a JIRA project that I have completely ignored in this tutorial, such as Epics, components, boards and queries. JIRA is an insanely powerful tool as well as an insanely complicated tool, and unfortunately often the complexity gets in the way of usability for a lot of teams and JIRA becomes a source of frustration rather than a source of information. If there’s one thing I could say to convince people to invest in JIRA, it’s the following:
JIRA allows you to visualize the consequences of scope change.
Picture this. A person with some level of authority barges into your area and talks to you about something that’s not accounted for anywhere that needs fixing ASAP. Sound familiar? It happens all the time. These kinds of interference all too often goes unnoticed because right then and there, in the heat of the moment, there is no metrics to measure the impact of such a request. It becomes a matter of “my word against yours”, “Why wouldn’t you comply with a request from management”, “How bad could it be”, “Its just a small change”, “How busy can you possibly be right now”. If JIRA is properly configured on the other hand, the impact of the request that resources be diverted away from their stated objectives can be measured immediately, and the offending manager can immediately be presented with evidence showing how his interference will push back the release date by so many days, or risk jeopardizing other features which are already accounted for.