Burndown charts today have become more popular in providing stakeholders as well as the team members the status whether a sprint goal is accomplished in an easy, understandable way or not.
Sprint burndown is a graphical representation of the estimated effort-hours remaining for a given period of time during a Sprint. Plotting the total effort-hours remaining for each incomplete task on a given day, on a graph, results in the sprint burndown chart which is significant for communicating progress as shown below.
The horizontal axis of the sprint burndown chart represents the days within a sprint, whereas the vertical axis represents the remaining estimated effort-hours. The chart should be updated every day to exhibit the total estimated effort remaining across all the uncompleted tasks.
It makes the teamwork visible. As the team is responsible for self-directing, self-managing, and self-organizing themselves to achieve greater success, the sprint burndown chart helps them to ‘see where they are’.
Sometimes, the team might not be able to specify the complete set of tasks required to design, build, integrate, and test the intended product backlog items. So, they can add new tasks corresponding to the intended product backlog items at any time to the sprint backlog. For instance, if on day 3 the team found that task 6 was missing, it can be added. There is no need to avoid a task from being added to the sprint backlog. As the understanding of the work enhances by doing it, the team can adjust the sprint backlog. This is where the sprint burndown chart comes into the picture which shows the team the work that needs to be done to complete a product backlog item that they promised to get done.
In simple words, we can say sprint burndown charts are helpful to track the amount of work remaining in a sprint backlog, see how quickly the team has finished the tasks, and predict when the team will reach the sprint goals.
The following individuals will be involved in Sprint burndown chart:
The team is responsible for making the ‘work in progress’ transparent to the stakeholders. The Product Owner decides whether the release plan needs to be updated or the project is on schedule. The Scrum Master supports, coaches, and reminds individuals of the rules underlying Agile software development.
The team members use it religiously during sprint execution to report the estimated effort remaining for each uncompleted task. Because, each day during the sprint the number of hours lasting for each task decreases since tasks are being worked on and finished. If the task is not started yet, the size of the task may remain the same every day until the task is begun. Sometimes its size may remain the same even after the team has started working on it or increases day over day, either since no work eventuated on the task the earlier day, or work took place the earlier day but the assessed effort remaining is the same.
The team evaluates the work for all the tasks it engaged in at the start of an iteration itself. Anytime we could assess a trend line depending on the historical data and utilize that trend line to check when we are probably going to complete if the current scope and pace stay consistent.
Fig: Sprint Burndown chart with trend lines
The three burndown lines that are overlapped as shown in the figure above demonstrate distinct situations.
By estimating the trend lines, we will get the data that shows us how we are managing flow within the sprint. This chart also helps in assessing the following:
On the whole, sprint burndown chart motivates team members at the individual level, offers a good vision for decision-making and task tracking activities, and enables the team to identify obstacles early.
The team members can adapt to changes easily with the help of this sprint burndown chart almost every sprint.
Very nicely written!
i want to know more as a scrum master
Why would you justify your phrase " the same holds true for a Scrum Master, who must understand the technical issues the team needs to address and the technologies the team will use to come up with end solutions." using the Scrum Guide? There's nowhere in the Scrum Guide saying that Scrum master must have technical knowledge, so I would like to understand what is the rationale /logic behind this phrase.
Okay thank you so much for the info and you have mentioned in the blog.
I am really happy to read this blog as I was stuck in this type of problem many times and your blog solves my problem in one go. I can't wait to see your next post soon.