Mastering JIRA Burn Up Charts for Effective Sprint Management
Written on
Understanding JIRA Burn Up Charts
In this guide, we'll explore how to efficiently configure a JIRA burn up chart, enabling you to engage in meaningful discussions about project timelines and deliverables.
Setting Up Your Chart
If you are unfamiliar with the traditional method of creating burn up charts, I recommend reviewing my earlier post that outlines a comprehensive, step-by-step approach.
Getting Started
To begin, you'll need the following:
- A designated start date
- A target date for project completion
- A list of product backlog items in JIRA that represents the overall scope
- Access to a sprint board in JIRA
Step-by-Step Instructions
We'll utilize JIRA’s version report to automatically generate the burn up chart. This feature is exclusively available when using sprint boards, and you can locate it in the left sidebar of your team’s sprint board:
#### Finding the Version Report
Before we can utilize this tool, we need to establish some prerequisites, particularly defining our project scope. This involves tagging all relevant product backlog items with the appropriate fixVersion in JIRA, which corresponds to a release.
#### Creating Your FixVersion
Since our fixVersion is not yet established, we must create it. This can be accomplished through the releases menu on the left sidebar of JIRA:
I've created a release labeled "Release 1":
Now that your release (fixVersion) is established, you can start associating all relevant items in your backlog with this fixVersion:
#### Reviewing the Version Report
Once you've tagged all pertinent items in your product backlog, return to the version report to ensure everything is accounted for.
Recap of Setup Steps
- Create a new fixVersion for your larger project.
- Set a suitable start and end date.
- Tag each product backlog item with this fixVersion.
- Collaboratively estimate the items in scope with your team.
- Review the version report.
Exploring the Version Report
In the following example, I’ve tagged three product backlog items with my fixVersion "Release 1". At the top of the report, you can see the details of the release:
Scrolling down past the chart reveals a summary of:
- Completed Issues
- Incomplete Issues
- Unestimated Issues
With this data, you can facilitate insightful discussions regarding progress towards your long-term objectives, whether that involves adjusting the scope or planning to estimate additional backlog items for improved forecasting.
Understanding the Chart
The chart illustrates your progress over time from the start date, as well as changes in scope. Initially, it might not provide much insight, but as you input data, it becomes increasingly useful.
JIRA calculates three key dates based on your team's velocity:
These dates are:
- Predicted completion date: When all backlog items are expected to be completed.
- Optimistic completion date: A projected early finish based on a 10% increase in velocity.
- Pessimistic completion date: A timeline if the team operates 10% slower than anticipated.
This information allows for a range of discussions about potential completion timelines based on real-time data captured by JIRA.
Utilizing the Report Effectively
I recommend using this report during sprint reviews every few weeks. It aligns team members with long-term product goals and fosters collaborative inspections of progress, enabling adjustments to future plans. This creates discussions around scope and helps developers make informed decisions in their daily tasks.
Important Considerations
#### Handling Multiple Teams
The version report is specific to the JIRA board it is created in. If multiple teams are collaborating towards a shared goal, you may need to set up an additional board that encompasses all teams to visualize cumulative work.
#### Marking Items as Complete
Ensure that your JIRA workflow correctly marks items as DONE and resolved. This needs to be the far-right column on your sprint board.
#### Setting the Start Date
The horizontal axis begins on the version’s start date, or if not set, the date of the first item added to the fixVersion. Accurate setting of the start date is crucial for forecasting.
#### Monitoring Unestimated Items
The chart's forecasting relies on available data, so a large number of unestimated items will hinder effective predictions.
#### Discussions on Velocity
While this chart may prompt stakeholders to push for faster work rates, doing so can lead to team burnout. It’s essential to adhere to agile principles that advocate for sustainable development.
Conclusion
If you’re using JIRA and require an automatically updating burn up chart, the built-in version report is a valuable tool. When utilized correctly, burn up charts can often replace overly intricate Gantt charts, empowering teams while reassuring stakeholders about project status.
By sharing information and guiding productive conversations at the right moments with the appropriate individuals, you can effectively leverage burn up charts.
I hope this guide assists you in creating your own burn up chart and achieving your long-term goals with your team!
Chapter 2: Practical Applications of JIRA Burn Up Charts
The first video titled "How to Use Jira Burndown Chart For More Effective Sprints!" provides insights on leveraging JIRA burndown charts for enhanced sprint efficiency.
The second video, "How to Create Burnup Chart in Jira," offers guidance on the process of creating burnup charts within JIRA to improve project tracking.