To help teams read the Release report and know when bottlenecks or project blockers might be occurring, we've collated various Release report charts below. Each chart has a description of key aspects of the report that you might notice in your own charts and what to do if you do spot similar trends.
A Release report that shows a project behind schedule
With every Release report, you should be closing Issues at a rate fast enough that the darkest purple dots align above or just level with the Desired velocity, or yellow line.
Ideally, work completed should be in line with, or just above, the desired velocity in order to hit your Desired end date. In the chart below, the team's completed points are well below the desired velocity slope. This suggests that they won’t complete the work committed in this release by the intended deadline.
If you're noticing your team is well below the yellow line, prompt a conversation around next steps and options:
- Reduce the scope of work in the Release. Use the Remove from scope option in the Issue's table. This keeps the issue in the Release, but modifies the chart to show you what would happen to the deadline of the Release if it were removed.
- Add more resources to the Release. This might mean shuffling capacity across projects or conversations about hiring.
- Change the deadline. If your desired end date is not a hard-deadline, you can edit the end date to see what happens with your velocity and predicted end date by bumping out when the Release will be launched.
Check for un-estimated work that might be skewing your velocity line
Issues that get added to the Release, but are un-estimated will be assigned an average story point number in the Report. However, the more work you estimate, the more accurate the report will be.
In this report, the difference between the Total Scope and Estimated Scope is fairly low, which indicates that the team did a good job of ensuring each Issue in the Release was assigned story points. However, if you notice a significant gap between these two figures, it's time to go back to backlog planning and refine your Issues to ensure your scope is accurately reflected to intercept with the end date to draw the Desired velocity line.
In the example below, this report is also indicating that this Release is off track, but shows a few different trends worth watching for in your projects:
- When the first few weeks are drastically below the desired velocity line, this could mean that the project hasn't been started in way that favors tackling small Issues, of relatively low complexity. Typically, the start of the project is where you'll have larger infrastructure Issues to get your foundation set. It's important to keep even these Issues small to stay agile and ensure you're closing Issues without blowing the scope of the project right at the beginning.
- When toggling the predicted end date on this early in the Release, it'll forecast a date far into the future. This is because the slope of your completed Issues is very low - the predicted end date will calculate based on this slope and where it intersects with the total scope of the Release. Be sure to use this as a data point, but not drastically reduce scope just yet in the Release. Instead, re-evaluate the size of your Issues and whether more resources need to be added to the Release first.
A stagnant or stale project / projects starting before being fully scoped
When you start to see lengthy periods of time of flatness, especially at the beginning of the project or in the middle, it could indicate that there is stale work, or the Release is no longer relevant. In the example below, there is no work that is being completed until several weeks after the start of the Release (October 26th). In addition, the Total Scope grows steadily for the first few weeks. This likely indicates that the team started work on the Release before it was fully scoped.
The sharp slope of Completed Points from October 28th to November 4th shows a good progression of work being completed. However, this immediately slows down, shown by the the long, flat period starting after Nov 4th. The team should take some time to diagnose this:
- Were Issues getting more complex and taking longer to close?
- Was there a change in team capacity?
- Were there other blockers?
You can also see that due to the stagnancy that did occur, the Release is past the due date by a few weeks with a third of the Release not yet completed. It's important to have scope and deadline conversations throughout the Release to make decisions about end dates before the project is coming to a close.
What an ideal Release report looks like
Below is a great example of an ideal release. The straight slope of the Completed Points line (dark purple dots) indicates that work is being completed in a steady, gradual manner. Although the team was initially closing Issues more slowly than the Desired Velocity, the pace picked up and they eventually got ahead of the desired velocity.
This is a great opportunity to reflect on what went well mid-Release to bring the team back on track and how they can apply those learnings to future releases. Because the team's velocity matched the Desired end date throughout the Release, there was very little reductions in scope. This is usually because there was good planning ahead of time to decide on scope, write out user stories, and plan before kicking off the project.
Review our complete Release report guide to create your first Release.