Don’t Miss Delivery Dates with Jira Version Reports

Jira Version Reports

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.

Screenful Review: Project Management Intelligence

screenful for intelligent project management

Over the years of supporting teams with their agility and tooling use (and hopefully both combined where possible!) it’s been a constant source of distress to hear of the hours wasted exporting data from tools like Jira, importing it into Excel, and jazzing things up a bit into some slides, usually for management to glance at. Even worse, by the time this data made its way through, it was often:

  • Subject to errors from processing
  • Already out of date

…at the same time, even for development team members, lots of the reporting built in to tools like Jira just isn’t visually compelling or consumable. Luckily for us, this has created a handy market for exciting innovators like Screenful!

Screenful integrates with one or more delivery tools including (for now – their roadmap is quite frighteningly rapid) Jira, Trello, GitHub, Pivotal Tracker, Asana, and GitLab… and in many cases fills gaps that can bump up functionality in these tools significantly (need Epics or Sprints in Trello? Screenful can fix that for you 😊 ).

Screenful Sprint Reporting

I’ve often been asked by clients and colleagues for a core set of recommended agile metrics as a starter for new teams (mostly Scrum), and whilst the answer is of course the perennial ‘it depends’, Screenful comes pretty close to offering an exceedingly good basic set to get started with. My two particular favourites to highlight hit 2 key areas – timing and forecasting. 

The Time Machine (Reporting Retros)

Possibly the most revealing, and often most uncomfortable, of lenses to help a team understand their agility is by looking at their cycle time. In many tools, creating a meaningful view of this takes a good deal of data munging and you end up with something that takes quite a lot of narrative – in Screenful you get it within about 30 seconds of install. The answer might not be comforting, but it is important:

Screenful lead time reporting

Up, up, and away!

My second favourite capability to empower teams with is a data-fed view of where they’re going. A versatile and configurable burnup chart is incredibly useful, particularly when making tough decisions about priorities, but can be a pain to maintain and tweak (“What happens if we focussed purely on X?”). Here again, Screenful provides a compelling and easy to understand format which can save hours of slideware production:

Screenful work remaining reporting

Yer a Wizard… admin

Powerful tools can often feel intimidating to setup. Screenful wins here also. Thanks to a slick UI setup wizard, the core capabilities are a breeze to setup. I often recall after one demo where a team had managed to setup their trial before my colleague had returned to his desk. As always there’s more tweaking to get things perfect, but getting a reassuringly rich initial setup is almost instant, which really helps alleviate initial fear of ‘another new tool’.

Tip: As with lots of tools, (if you’re using Screenful via API rather than as a plugin) it’s worth setting up a service account to use for accessing your instance. This is better for various security reasons (not least that you can give it least-privileged and read-only access) but also more convenient to cope with staff transitions. 

No regrets

Screenful is easy to check out with a free trial, and configuration of a quick proof of concept takes single digital minutes – vastly quicker than most other tools. I’ve encouraged huge numbers of teams to give it a go, and even if it’s not right for them in the end, thinking about the core metrics and views it provides helps them consider how and what data they visualise about their work in future.

Achieve Whole Team Ownership with Jira Sprint Reports

Jira Sprint Report

The Jira Sprint Report is a Scrum team’s best friend and one of several key reports in Jira that help teams gain valuable insights on a daily basis. First and foremost, it lets you know how you’re sprint is doing in terms of progress, priorities and burndown. It also encourages conversations between team members about any progress interruptions, effects of scope changes, and improvements that can be made on the next sprint. 

Importantly, it helps you achieve whole team ownership, a concept that many organizations struggle with. 

This article explores the benefits of Jira Sprint Reports and how they foster shared responsibility and accountability across development teams.

Whole Team Ownership

What is whole team ownership? Let’s look first at the opposite model. A team focused on individual ownership has people who have a specific role and don’t typically act outside of their remit. They own the tasks they’re assigned and other team members should go through them if they have something to contribute. This is all well and good when everything’s running like clockwork. But it can be a challenge when that particular process owner is unavailable or there’s a breakdown in communication. 

Whole team ownership is about pulling down the walls between team members. These teams share responsibility, holding themselves—and each other—accountable for the team’s overall success. With whole team ownership, handing over work to a team member is more than sending an email or assigning an issue or ticket to them. It involves a conversation to confirm that all the relevant information is included and the next steps are clear. Every member of the team has the ability to impact each step, and everyone speaks up with concerns and questions to help make sure there is a collective understanding of the topic at hand. 

Jira Sprint Reports help shift responsibility from the individual to the team as a whole, by facilitating conversations that bring team members together in pursuit of a common goal.

What is the Jira Sprint Report?

The Jira Sprint Report gives Scrum teams visibility of their sprint progress and sprint dynamics. It shows the burndown of work, so you can visualize how you’re doing relative to where you are in the sprint. It allows you to identify what might be stopping you from finishing everything you’ve committed to the sprint.

Burndown charts commonly use Story Points (1), but can also use hours as a metric. The grey line (3), based on the total estimate of the issues at the start of the sprint, is your guideline. The red line (2) is the actual work done. It shows the current total estimate for unresolved issues during the sprint and reflects issues that may have been added to or removed from the sprint. 

The Jira Sprint Report also gives Scrum teams a great view of their sprint dynamics by listing completed and not-completed issues. A little asterisk appears next to any issues that are added to the sprint, giving you valuable insight each day on whether the scope of the sprint is changing. These are things that are hard to see on your sprint board or in the backlog view. 

Jira Sprint Reports also list your priorities. You’re able to see if there’s a load of high-priority incomplete issues, encouraging conversations between team members about whether you’re working on the right things in the right order.

The data displayed in a Jira Sprint Report can be used for mid-sprint progress checks and discussed during the daily stand-up. Equally it is useful for retrospective conversations. You can talk about what incomplete issues have been rolled over to the next sprint and why, and evaluate the reasons for any straight horizontal or vertical lines partway through the sprint. 

In short, the Jira Sprint Report lets you visualise the progress of your sprints and measure team success, both in the short term (are we on track to complete our sprint goal?) and the long term (are we delivering what and when we say we will?).

Note that the Jira Sprint Report is board-specific and will only consume the data that matches your board’s saved filters.

What’s Great about Jira Sprint Reports?

The Jira Sprint Report supports and facilitates the micro-planning that should be happening in your daily stand-ups, enabling you to stay on track with achieving your sprint goal. It also triggers useful discussions in retrospect, improving the quality of future sprints. Teams can ask the following questions:

  • What were the scope changes? Were any good or bad?
  • Were any stories added to the sprint that were unestimated? 
  • Did we complete all the high-priority stories?
  • Did any high-priority stories get rolled over?
  • Was there a steadily descending line on the burndown chart with a sudden drop-off at the end? This normally means that you’re handing everything over to Quality Assurance (QA) at the end of the sprint, triggering a further question…
  • How are we going to start handing over work more incrementally to QA in the future?

What’s particularly useful about the Jira Sprint Report is that it breaks down functional silos and fosters whole team ownership of the progress and quality of a sprint, and the processes therein. It encourages team members to talk to each other about how they’re going to move the team forwards, and to share responsibility for the team’s successes and failures. The sorts of questions listed above can only really be answered by the whole team coming together. 

The end result? More effective sprints, and more effective teams.

Now you’ve got the hang of Jira sprint reporting, it’s time to go faster! Check out this blog on Jira Velocity Charts

How to Use Reports in Jira – the Basics

Reports-for-Jira-Basics

Reports in Jira help everyone analyze the progress of a project, track issues, and manage time and sprints. Provided you are using Jira to manage your projects, reporting is something you will do every day. However, for someone using Jira for the first time, things can get a little complicated. Finding your way around with reports can be painstakingly challenging and time-consuming. 

Jira simplifies projects by streamlining team activities, and highlighting useful snapshots around dashboards. Through Jira, teams perform tasks in sprints or scrums. Most importantly, reporting on progress helps teams to continuously evaluate performance. The ability to zoom in and drill down on important issues is the key to using Jira productively. This post will guide you on how to use reports in Jira but first, let’s explore why the basics of Jira project reporting is crucial. 

There are different types of issues and projects that Jira administrators can create, assign, and manage within Jira. They include Kanban software development, project management, task management, process management, Scrum software development, and basic software development.

Types of Reports in Jira

Jira helps manage projects but also is an issue tracking tool, so creating reports forms an integral part of everything you do with it. The more Jira projects/issues you create, the more reports you will need. 

In Jira, there are four main types of reports:

1.) Jira Agile Boards

2.) Forecast & management

3.) Issue analysis

4.) The others.

Between these four, there are all kinds of reports to be made:

  • Time tracking reports.
  • Scrum project reports.
  • Kanban project reports. 
  • Pie Chart Reports.
  • Created vs. resolved issue reports.
  • Version workload reports.
  • Version time tracking reports.

Using Reports in Jira – the Basics

These reports help project managers allocate and analyze the utilization of sources assigned to teams. For example, budget allocation and usage tracking within Jira ensure productivity and effective resource utilization.  So the first step to using reports in Jira is learning how to generate one.

Steps to Generating and Accessing Reports in Jira

To generate a report in Jira, navigate to your Kanban, or Scrum board. Next, click ‘reports’ to view the last one you created. If you want to view all or a different report, click ‘switch reports’. Note that in the first instance, you can only view reports from agile development projects.  Upon clicking ‘switch reports’ on the agile board, you will see reports such as a burndown chart, control chart, Jira velocity charts, cumulative flow diagram, and sprint report.

Provided you have an ongoing project, you can access reports easily with a few clicks. Navigate to the specific project, and locate the menu for projects between dashboards and issues at the top.

Basic Features of Jira Reports

To use Jira reports effectively, you should understand what each report is showing, as well as the features of each report generated

The following are the main reports you can access and use in Jira:

Agile Reports in Jira

Burn-down charts tracks the quantity of pending work and the efficiency of each sprint. A sprint chart is another agile report, tracking completed tasks and feature backlog. Other features include cumulative flow diagrams, velocity charts, version reports, epic reports, control charts, release burn down, and epic burndown charts.

Forecast and Management Reports in Jira

Forecast and management reports include time tracking reports, version workload reports, and user workload reports. You will note that the forecast and management reports detail time estimates for every assigned issue.

Jira Issue Analysis Reports

Issue analysis reports give an average age report that shows the duration of unresolved issues. Another feature of this report is a pie chart report that groups projects based on specialization. Analysis reports include resolution time reports, created vs. resolved issue reports, reports on recently created issues, and reports on time since an issue was assigned.

The Bottom Line

The usefulness of reports in Jira boils down to understanding when, why and how to create Jira Reports. Jira admins and project managers can, therefore, proceed to implement necessary changes based on issues identified in the reports generated from different boards and Jira Dashboards.