Today I’m excited to announce the availability of the new release burndown chart inside of Jira Agile labs. The release burndown chart gives the team clear insight into the evolution of a release throughout its life cycle.
It’s every scrum software team’s goal to deliver new features and optimizations to their customer base. Many software teams bucket chunks of work for a release into a version inside of Jira. A version is a distinct piece of software that is shipped to customers. During development, it’s easy though to add scope to your release. What are some causes of scope creep?
- A feature needs to work differently based on user feedback
- Market demand shifts require a different feature set
- Estimates change as the team learns more during implementation
Each of these changes need to be clear across the team so that everyone’s expectations remain in sync. Scope creep can not only delay your release date, it can also introduce unnecessary code and risk to the software. Scope change over a release isn’t always a bad thing, but whenever scope changes, expectations need to be reset across the board for product owners, team members, and stakeholders. Agile businesses are not in the business of surprises. The release burndown chart makes scope change clear, sprint by sprint.
Let’s take a glance at the new release burndown chart.
The new release burndown report in Jira Agile includes 4 major sections.
- Built in guidance: The top of the chart has easy to understand examples which explain how to use the chart.
- Your release burndown: The chart shows the inflow and outflow of work between the start and finish of the version selected.
- Completed issues: All issues for each sprint in the release are listed below the burndown chart.
- Feedback: As these features are in labs, please give us feedback as you use them.
Proceed with clarity
At some point in our careers, we’ve all been on a project that took way longer than expected, burned our people out, and left a bad taste in everyone’s mouth. Honest retrospectives can be extremely insightful after the fact, but being proactive is better than being reactive. The new release burndown chart gives real-time feedback into the project’s evolution so that the team remains in control of their destiny.
Versions in Jira are distinct increments of software that usually ship to customers. An agile team often works in iterations or sprints that deliver value back to the customer. Teams that deliver releases of software in versions over several iterations will find the release burndown chart invaluable.
Once an agile team masters the basics of working in iterations, the next step is understanding the delivery cadence of their software. I’d like to focus in on four key metrics to review each and every sprint (see example below).
1. Work remaining
Work remaining includes all known outstanding estimated work from the current point in time to the team’s goal. Beware of unestimated work. Tickets that are unestimated represent the biggest risk in any project’s success.
2. Work added
After the project commences, the team will learn new information required to meet the market need, and sometimes that means taking on additional work in the release. The new release burndown chart clearly calls out work that is added to the release. Teams can stay on top of, challenge, and ultimately reduce scope creep to maintain the integrity of their release.
3. Work completed
Each iteration returns value back to the customer. Teams can easily track their progress throughout the release showing how much work they deliver.
If the team is only working on this release, work completed over time mirrors velocity. Often times, though, teams will have to work across releases. The release burndown chart is release specific so it’s easy to see progress independently per release. The velocity chart still provides a team-level view of their velocity.
4. Work forecast
Jira Agile helps project managers stay in touch with day-to-day development. As the team gets closer to delivery, Jira Agile forecasts projected delivery dates based on the team’s velocity over the prior sprints.
Change is a reality in every agile team. The release burndown chart makes it easy to drill down into a sprint and understand each of the four components above. You can see what the team has completed as well as how scope changed. Just click on one of the bars for detailed metrics as well as a link to the sprint report for that iteration.
Communicating with stakeholders
Stakeholders often want to understand how the product is evolving over time. The release burndown chart highlights all of the completed issues by iteration. Product teams often have to communicate with release and operations teams. The release burndown chart lets the operations group know what changes are in each build. There is also a link to each issue in Jira for full visibility into changes by iteration.
Following scope change
Scope creep is the addition of work outside of the original commitment made by the team. Scope creep isn’t always bad, but it needs to be understood across the business so the team can actively (and accountably) take on new work. A scrum team can have scope creep inside of a sprint or a release.
Sprint scope creep
Scope creep during a sprint happens when the team accepts new work into a sprint while the sprint is active. The sprint report clearly shows sprint scope creep. It’s extremely important to keep the integrity of the sprint commitment. Teams that break the sprint commitment have a hard time validating their estimates and maintaining a predictable velocity, both of which are critical in forecasting release cadence.
Release scope creep
Release scope creep (1-3 below) is similar to sprint scope creep as it’s new work added to a release. It’s natural to evolve a release as the team learns more about the release goals. The release burndown chart only shows release scope change. Work that’s added to a sprint that’s a part of the release is only scope change for the release. It won’t show in the release burndown chart as scope change as it’s already a part of the release.
Let’s look at a release burn down chart where the team added new work to the release during two sprints:
The team added 2 story points in sprint 8 (#1) and another 4 story points in sprint 9 (#2). We can also see that the y-axis on the chart adjusted to the total add of 6 story points to the release. The original forecast is still at the zero point and new scope shows below the zero line.
We’ve included an option to the align sprints at the base of the chart. We’re curious to know which view resonates better with your teams. Feel free to let us know in the comments.
Interested in learning more about metrics? Head over to The Agile Coach and learn about how to track and share sound agile metrics to reduce confusion and shine a light on your team’s progress.