The Scrum Guide does not mandate the use a burndown chart to monitor progress. Scrum requires only that Remaining work for a Sprint is summed up and made known on a daily basis and that trending toward completing the work of the Sprint is maintained throughout the Sprint (Scrum Guide). Although the Scrum Guide, even not in the 2017 update, does not mandate the use of a burndown chart, I do advice Scrum Masters to use the burndown chart because it can tell you so much about the Scrum team.
Because I found myself repeating a lot of what the burndown chart can reveal, I decided to write down the most common patterns I have.
This is how the burndown chart usually looks for teams just getting started. This is, of course, assuming that the team can reach the Sprint goal at all. Teams who have a similar burndown chart usually have team members assigned to a story. This is also the reason why the first stories which meet the Definition of Done (DoD) are pretty late in the Sprint. It could very much be that testing is still done by a specific team member and not by the whole team. I usually advise the Product Owner to ask the team at the beginning of the second week (in a two-week Sprint) how they feel about realizing the Sprint goal and which of the stories they feel confident about and which ones they are a little worried about. In this situation, the Scrum Master has to challenge the team on meeting the DoD. This is very important to take into account, it is not uncommon that team members ignore the quality standards of the DoD to finish before the end of the Sprint.
Most teams start laughing when I tell them that Super Mario has joined them in the Sprint. Luckily, the team then quickly starts to analyze what happened in the Sprint. Usually, two main reasons are mentioned for the Super Mario burn down. The first one is that the team has added new stories to the Sprint. Digging deeper, it is not the team which has added new stories, it is the Product Owner who has asked, read "demanded," to add new stories because ... well, there are enough excuses to add new stories to the Sprint. Scrum Masters must be aware and discuss this behavior with the Product Owner and challenge the backlog to eliminate the need to add stories to the running Sprint. also, it is wise to coach the team members to say NO to interruptions and additions to the Sprint.
The second common reason is that there is still a lot of discussion about the DoD. Team members have closed the story and after discussion, they reopen the story because the story does not meet the DoD. Firstly, the Scrum Master must be happy that the focus on quality is at the front of the team's mind. Additionally, the Scrum Master can challenge the team to improve the process of the DoD so that the whole team agrees on what the DoD should look like.
The Big Finish
Even if the team starts the Sprint off strong by finishing a couple of stores, a big challenge still lies ahead. Usually, such burndown charts reveal that the team did not succeed in breaking all stories into smaller stories. Obviously, the team can be challenged during the refinement sessions to make the stories smaller. Another reason can be that the team did not realize that bigger stories are risky to save for the end of the Sprint. It could be that the team is focussing on finishing the stories based on the priority set by the PO. However, the team must not only focus on the initial priority but create a strategy to finish the stories, or anything needed to realize the Sprint goal. In that case, it is better to start with the bigger stories and leave the smaller stories for later in the Sprint.
The Nearly Perfect Burndown
The ultimate dream of each Scrum Master and Product Owner is the nearly perfect burndown. This burndown reveals that the team has the Sprint under control. The user stories are small enough that they can each be finished within a few days. The chances are that the whole team is working on one or only on a few stories at a time. For the Product Owner, this burndown provides the predictability to update the stakeholders and to prepare for the Sprint review. Although I really like the nearly perfect burn down, I do get suspicious when I see this kind of burndown pattern for a few Sprints. I usually advise the Product Owner to challenge the team and "force" them to commit more.
I hope this article helps you to look differently at the burndown chart and see what is really going on within the team. And I am also curious which patterns you have encountered and what it tells you about the team.