After seeing how your team spends time with the time allocation report, the next layer that’s important to understand is how tickets flow through sprints.
The sprint trends report illustrates the flow of work by total estimate quantity. The estimate units can be either story points, original time estimates, or ticket count if there are no estimates (unestimated tickets will default to 1 story point).
By default, the bar for each sprint is scaled relative to the total number of estimate units in the sprint when it started, which you can see with the dotted black line in this screen shot:
|Figure 1. Sprint Trends report for team that comes in somewhat below sprint commitments and has somewhat high rollover. There is one sprint with a spike of work added after start.|
The report then breaks down estimate units into several categories. Overall, the solid green, teal, blue, and purple categories represent tickets completed in the sprint, while lighter yellow, red, and gray categories above represent incomplete work. The specific categories we identify here are:
Note: This report will show a row for each scrum board in your organization. We are working on support for kanban boards in this report. If you’d like access to the beta version of Kanban trends, please contact us.
There are a few main things that you should look for when assessing the sprint trends report.
The first and most important metric is overall estimate units completed relative to the commitment. The very best teams will regularly complete 80-120% of their commitment, meaning that they are able to accurately predict how much work they will get done.
The screen shot in Figure 1 shows consistent completion in the 60% range, which is still good, but could benefit from reducing the size of sprint commitments. What you don’t want to see is sub-40% completion, which indicates that the sprint commitment is essentially meaningless, as shown in the screen shot in Figure 2 below:
|Figure 2. Sprint Trends report for team that consistently completes far less than its planned sprint commitment (completed points in dark green, teal, blue purple colors).|
The next thing to assess is the portion of completed work that rolled over from previous sprints versus completed work that first showed up in the current sprint.
Here, your goals may depend on your team’s release process. For teams that do continuous deployment, some rollover may not be a big deal because those tasks can launch early in the following sprint. Rollover is a bigger problem for teams that release less frequently (e.g., if doing mobile app store releases) because missing the end of the sprint means waiting longer to release.
Regardless of your release process, however, multiple rollover is always bad because it means that tasks are taking longer than an entire sprint from start to finish, which breaks the idea of a sprint commitment.
Generally speaking, rollover ratios of less than 30% of completed work (single and multi-rollover) are healthy. The screen shot in Figure 1 is just above this mark and could benefit from breaking down tickets and reducing sprint scope to decrease rollover.
The screen shot in Figure 2 is way over with a majority of the completed work rolling over. What’s happening here is that most tickets are taking multiple sprints from start to finish, which you can further infer from the large amount of yellow “In Progress” work.
While adding tickets to a sprint after it starts may not impact the team’s overall velocity, it means that the team is doing unplanned work and has less capacity for planned projects. This may be fine if the team is responsible for responding to a lot of time-sensitive issues, but it can also indicate lack of planning or inadequate testing that results in a lot of urgent bugs.
Generally speaking, if you see over 30% of work added after the start, it is worth digging into to understand the root cause.
In the Figure 1 screen shot, the one sprint with a big spike of work added after start coincides with a sprint where a large number of bugs were discovered and fixed. This may be okay if it is intermittent, but warrants investigation if it’s happening regularly, as seen in the screen shot below in Figure 3 (even though the team’s velocity exceeds the overall commitment):
|Figure 3. Sprint Trends report for team that meets point commitments but has a large amount of work added after the start of the sprint (in purple).|
It is a general best practice to remove things from the sprint as soon as it’s clear they will not complete by the end. This makes it easier for stakeholders to know what to expect. To assess this, compare the amount of light red work (tickets that did not start and were not removed from the sprint) to light gray to see whether removals are happening on a regular basis.
The Figure 1 screen shot above shows good removal practices in the later part of the chart, whereas the Figure 2 screen shot above has hardly any removals.
Because the sprint trends report provides a high-level overview of sprint completion, we recommend reviewing it on a strategic cadence, like the time allocation report.
This means reviewing it at the start of planning intervals (e.g., quarterly) to set priorities, and then reviewing it at the end of each sprint while there are specific ongoing initiatives to improve the results.
Senior leaders should review this report to gain a base understanding of where each team is at in terms of process maturity. This allows them to know which teams need the most help and better understand challenges they face, such as high rollover being caused by slow QA processes or high tickets added after start resulting in too many urgent requests coming from outside the team.
Individual team managers, scrum masters, and product owners may also find this report helpful to review at the end of each sprint to see how their progress is trending over time, though the Sprint Insights report provides more ticket-level detail and a burndown chart that is more appropriate for sprint retrospectives.
While it is generally good to meet sprint commitments for the sake of predictability, be very careful about putting too much emphasis on exact sprint completion. The obvious reason for this is that when performance reviews are on the line, it is easy for teams to just put way less stuff in the sprint than they can complete so that they will never miss a commitment, effectively completing less work overall just to smooth out the numbers.
It is also very important for senior managers to solicit context from people on the team before drawing any conclusions about the numbers. While there are some things largely under the team’s control like task size and estimate accuracy, more often than not the underlying cause of sprint problems lies outside the team, such as changing or ambiguous business requirements, external dependencies, technical debt, or slow QA/deployment processes. When viewing this report, the default stance for managers should be: What help does the team need from me to have a healthier process?
Sprint trends provides a high-level overview of how tickets flow through sprints in a scrum process, helping visualize bottlenecks and issues on each team. This report is great for seeing long-term trends, informing strategic priorities, and tracking improvements related to sprint task flow.
Here are cases where other minware reports may provide more relevant insights than the sprint trends report:
If you’re following the walkthrough series, we recommend reading about the Scorecard report next.