In this article I want to describe how, in practice, we use the Burn Down Chart while working within SAFe.
Let me start with the most interesting point. The use of this chart inside SAFe should not really be any different from its use in Scrum. Or should it?
In our environment, SAFe differs in having a role such as the RTE, whereas Scrum does not. But a Burn Down Chart is a tool for tracking sprint scope and progress, and first and foremost it is needed by the Scrum team itself, not by someone outside the team. Would you agree?
So let me move on to how we use the Burn Down Chart in practice, despite everything, while still remaining inside the SAFe framework.
I work in the role of Scrum Master, and I try to surface this chart daily for the entire Dev Team. The tool I use is the team chat: I mention the whole team with “@” and post a screenshot of the current chart. Mentioning the entire team is a subtle instrument, and it is important to use it as rarely as possible, because as Scrum Masters we are supposed to help the team work comfortably and with minimal unnecessary context switching.
As a result, the team sees the current sprint state every day and can track events such as the following:
- The appearance of unplanned work
- Tasks remaining unfinished for too long
- Excessive risk padding
- Whether the team is working at an appropriate pace
Below I will try to unpack each of these signals and give examples from my own practice.
The appearance of unplanned work
This chart shows very clearly how new work appears in the middle of a sprint, in this example on the second Tuesday of a two-week sprint.
A practical example: a developer, as a member of the Scrum team who genuinely shares Agile principles, interacts directly and effectively with the Product Owner. The Product Owner says, “We need to build this quickly; you know yourself, it’s fast and the risks are minimal.”
The developer is a good one, understands Agile, understands the importance of delivering business value, and goes ahead and adds a story from the backlog to the board. The team had previously estimated it at 6 story points.
The rest of the team, everyone except the developer and the Product Owner, notices this on the morning chart update. During the stand-up the team decides what to do with the situation. Most likely the story is removed from the sprint, and the team makes it clear to both the Product Owner and the developer that this is not how changes should be introduced. If needed, the Product Owner can bring the story into the next sprint.
Ideally, of course, the team should notice new work appearing during the stand-up even without the chart. But the chart is a strong indicator that reduces the risk of missing such an important change for the whole team.
It is important to understand that the scenario can play out differently depending on the team’s maturity. In strong teams, a Product Owner is unlikely to do this. And if they did, the argument would not be “this can be done quickly”, but rather something like “I estimate a 55 percent probability that if we do this now it will increase our profit by 20 percent next month,” or some other measurable business metric.
Tasks remaining unfinished for too long
Here we see that work is not being completed, not even partially, for too long. This can indicate different kinds of problems, including the following:
-
Poor task decomposition
Very often, less experienced teams say that decomposition is impossible. Everything burns down on the final day, work does not get parallelized, and so on. This is exactly the kind of issue a Scrum Master needs to work through with the team by explaining the value of decomposition.
-
A suboptimal Definition of Done
DOD, Definition of Done, is the description of readiness criteria for a User Story inside the sprint. Sometimes teams do not have one at all, or it is written in a very abstract way. That can easily become a real problem, and naturally it is something a Scrum Master should help the team solve.
Excessive risk padding
In this case we see a situation where the team has padded in too much risk.
Perhaps one of the stories was overestimated. Perhaps the issue is more systemic and the team should increase the amount of work it commits to during sprint planning. In any case, the situation is not ideal. The business planned for the sprint scope to be delivered by the end of the sprint. Depending on how dependencies were planned, this often means additional conversations are needed to reset expectations.
I have seen this happen when a simpler solution was discovered than the one discussed during estimation. We reviewed as a team which story could still be closed before the end of the sprint, and during the retrospective we agreed that during refinement we would try to look at the code more often. It turned out that simply checking the code would have made it obvious that the solution was much easier than we originally thought.
Understanding whether the team is working at the right pace
Here I want to highlight visually poor ways of presenting a Burn Down Chart.
The upper part of the image shows an example of a less successful graphic implementation for two reasons, which I outline below.
-
New story points entering the sprint are hard to see
In the upper chart it is almost impossible to notice that unplanned work was added. In the lower one it is much more obvious.
-
The relative amount of remaining work is displayed inaccurately
According to the upper chart, there appear to be three working days left. In reality there are only two, and some people may well be planning to rest on the weekend.
Of course, some people may see such details as insignificant. But it is important to remember that each team member will only glance at this chart for a moment, so it should communicate the maximum amount of useful information immediately.