Many people don’t know about Jira Version Reports, and even if they do, they might not have realized just how valuable they are (or how to make them valuable). And yet, Jira Version Reports (sometimes called Jira Fix Version Reports) are fantastic for tracking a Scrum team’s progress on a version and understanding what the delivery timeline is likely to look like. They’re particularly useful for product owners, project or program managers, and stakeholders.
This article reveals how the Jira Version Report provides excellent visibility of your delivery timeline so that you can manage risk, identify uncertainty, and find ways of staying on track. It also includes tips for how to get the best out of the report.
What is the Jira Version Report?
The Jira Version Report shows your team’s progress towards the completion of a version. It also gives you a predicted release date based on your team’s average rate of progress (their velocity) since starting the version, and the amount of estimated work that remains.
The grey area
The grey area shows the scope of estimated issues to be remedied, and any change in the size of the grey area indicates that the scope of the work has changed.
The blue line
The blue line shows the progress made by demonstrating how many story points are being completed over a set period of time. The slope of the line is based on the team’s average daily velocity.
Where the blue line hits the top of the grey area gives you the predicted release date, i.e. the date on which you can expect all the issues in the version to have been fixed/completed. This is based on your average daily velocity and the amount of estimated work remaining.
The shaded blue areas
The shaded areas straddling the blue line give you the predicted release date range, aka the best-to-worst case scenario for the release date. The shaded area to the left of the blue line gives you the earliest date by which you might expect completion of the version (the optimistic date). The area to the right of the blue line gives you the latest date by which you might expect completion of the version (the pessimistic date).
The red line
The red line shows you what percentage of issues are unestimated. Since the predicted release date and date range are based in part on the estimated work remaining, ideally you want most of your issues to be estimated. That would make the red line low. If the red line is low, it means you can have a decent amount of confidence in the predicted dates. But if the red line is high, meaning lots of your issues are unestimated, then the date range might paint a less accurate or realistic picture of what’s happening.
Keep on Top of Estimates and Keep Jira Statuses Up-to-Date
The Jira Version Report requires the use of the fix version field and, if you want to get real value from the report, most of the issues to be remedied need to be estimated. In other words, that red line of unestimated issues should be low. The more of the fix version you have estimated the better because this will allow you to have more confidence in the predicted release dates.
You want to make sure you keep your current statuses up to date, too, as this is what’s driving the daily velocity and the slope of your blue line. So, if a piece of work is done, put it in ‘Done’. Teams that are somewhat lax about moving things through the workflow are going to find the Jira Version Report less valuable.
What’s great about the Jira Version Report?
The Jira Version Report gives you an instant view of potential release dates as well as any changes in scope on a particular version. It gives you a better sense of the risk in your delivery timeline, which a lot of reports don’t. It also lets you know what your uncertainty is and allows you to measure it. Specifically, as you get more and more issues estimated and your team’s velocity towards the fix version stabilizes, the blue shaded range will start to narrow, indicating an increase in certainty about the release date.
Most importantly, the Jira Version Report is great for prompting conversations about your delivery timeline early rather than late, when you’re about to miss your delivery date. It’s always better to know in June if you’re going to miss your August delivery date than in August. It means you can decide at that point whether there’s still a way to stay on track, e.g. by decreasing scope or by increasing your team capacity. Equally, your conversations might be about the fact that you’re set to deliver early and whether to add scope.
In conclusion, the Jira Version Report is a super-useful tool for predicting when a release will be ready, for checking how a team is progressing, and for triggering discussions about how to make that progress more fruitful.
“If we’re not making mistakes, we’re not trying hard enough.”