In Scrum or Kanban agile, one of the fundamental needs is to measure performance. Jira Software offers a relevant functionality: reports. Indeed, inspection, i.e. the measurement of a certain number of indicators or metrics, is one of the three pillars of the agile method (see also the articles on agility measurements).
Jira offers integrated reports, but few people use them because they don't know how to use them.
And yet, Jira reports contain valuable and even essential information for teams. And you can access this data without any problem. We would like to remind you of three basic requirements for optimal use:
- It is important to identify to whom the reports are addressed
- It is necessary to analyze the information they give
- There are certain data that you need to fill in on a daily basis, as these are the data on which the reports are based
Who are the Jira reports for?
Jira reports are not intended for the company's management. They are not intended to be used to define strategy. They are not used for long-term planning, nor for the analysis of interdependencies between projects. The software editor Atlassian offers tools dedicated to these uses (for example, Advanced Roadmaps, or Jira Align).
Jira reports are primarily intended for project teams. They are useful for the whole agile team: Product Owner, developers and Scrum Master. The objective of these three roles is to monitor the progress of the project and adapt it as needed. Thus, the Jira reports help the team to follow what is done and what remains to be done. It is a picture of the project at the moment "T". The team analyzes this information to ensure continuous improvement.
What information can be found in the Jira reports?
Jira Software reports are closely related to the agile project tracking charts and their settings (filters). For example, if you have 3 distinct tables, one for team A, another for team B and a third, multi-team, for bug tracking, you will have very different reports in these 3 tables.
Moreover, you will not get the same reports depending on the type of agile board Scrum or Kanban, the time scale being very different between these two boards. In the Scrum method, the time constraint is more rhythmic because of the Sprints, unlike in Kanban. Scrum reports will be more numerous because they will be subject to this constraint.
Here is an example of a Kanban report: Cumulative Flow Diagram
The diagram shows the status of requests over time. This report especially helps to identify possible bottlenecks.
In this report, we distinguish the total number of requests (more than 1000), classified according to their status. The team has completed more than 700 applications and there are still 200 to be addressed.
Moreover, we can see that this is a long project with a small staff. Indeed, the number of requests in progress ("In Progress") and in test ("In Test") is much lower than what remains to be done. On the other hand, there is no bottleneck on the project: the number of "In Progress" and "In Test" requests remains stable.
It is possible to refine this report according to time, status and quick filters.
Examples of Scrum reports
The reports have the same functionality when using Scrum boards.
Sprint Report
Here are two examples of Jira Sprint reports. The first one would correspond to the almost "ideal" report. The second one represents what is often found by Jira users.
In the reports, the grey curve indicates the estimated amount of work, the red curve the completed work. The horizontal axis of the graph represents the time, while the vertical axis prioritizes the value of the requests.
Below the graph, we find the details of the Sprint, namely:
- Completed applications
- Current requests
- Requests from the Sprint
- Requests added during the Sprint
- Applications for which the estimate was changed
Why is the first example of the Jira report "ideal"? The realization curve follows almost perfectly the forecast curve. The team was even ahead of schedule at times. They completed all the User Stories, except one, during the Sprint. The only drawback in this report is that the priority is the same for all the requests, which is impossible in reality - there are always requests with higher priority than others.
The second example shows a much more eventful Sprint. The Burndown chart shows that :
- The team did not complete half of the planned requests (the red and grey curves do not meet at the end)
- The team has added unplanned requests during the sprint (identified on the list with a star) and the red curve goes up again
- The estimation of some requests has been modified (shown by in the list by the arrows):
- Only some of the bugs appear as new applications. In principle, Bugs should not appear (they do not bring any added value and represent, on the contrary, a technical debt). However, if the team decides to estimate Bugs, it must remain consistent and estimate all Bugs without exception
How to better use Jira Software reports?
It is necessary to check three points:
- For Scrum and Kanban reporting, there is a subtlety that relates to request resolution. In a table, a request is considered "completed" when it is in the last column. This is true even if the "Resolution" field is filled in. This point is essential.
- Use the filters to refine your reports.
- For Scrum boards:
- a. Divide your Backlog into User Stories to get the necessary level of detail
- b. Estimate each of the User Stories or, at the very least, set up your chart to count the number of Stories. This is necessary for the Sprint reports, as well as for the Velocity Chart
- c. Position the Stories on the Sprint before running the report
- d. Keep the duration of the Sprints fixed
- e. Don't wait for the Sprint Review day to move the Stories forward
- f. Use Epics and Versions to make forecasts
Conclusion: don't wait to use Jira's agile reports
Jira's reports offer a very simple and inexpensive way to obtain valuable indicators on the team's activity: its velocity, the work it has accomplished during the Sprint, the bottlenecks it may encounter and much more!
You just need to get to grips with them: test them to understand what they can do for you and be careful when entering the information required for these reports.
To go further: better use of agile terms in Jira Software
These Jira reports are based on the basic concepts of the Agile method:
- Backlog
- User Story
- Epic
- Version
- Sprint
It is essential to understand and grasp these agile terms, otherwise the Jira reports will be meaningless.
Become familiar with these notions, go from theory to practice in Jira. The video of the Webinar " Story, Epic, Sprint, Version: how to use these agile terms in JIRA software " can be found on the SmartView Youtube channel!
