Based on its understanding of its capacity, its velocity and its estimate of the effort required to develop the top Product Backlog Items (PBIs), the Development Team has agreed to a Sprint Goal; and created its development and construction plan in the form of a Sprint Backlog.
✥ ✥ ✥
The Development Team members are typically strongly focused on engineering tasks, but they also form a Self-Managing Team. It is important that team members have timely access to information about their progress towards meeting their forecast, so that they can pivot immediately if necessary.
There are too many unknowns for the team’s delivery forecast to be a guarantee, and yet the statement of the Sprint Goal and the team’s forecast delivery have raised stakeholders’ expectations.
If it turns out that the Development Team has overestimated its capacity for work, the Scrum Team needs to be able to communicate this to stakeholders (perhaps directly, perhaps through the Product Owner) as early as possible. It may even be necessary to escalate into Emergency Procedure, so that the Scrum Team, and possibly the business and customers, can collaborate to find a solution.
If on the other hand the Development Team turns out to have significantly overestimated the effort needed to turn PBIs into a potentially shippable increment, then it will have spare capacity at the end of the Sprint. The Scrum Team as a whole needs to decide how best to use that capacity.
This might result in PBIs that the team originally anticipated would be developed in the next Sprint being brought forward for development by the Product Owner, possibly requiring a refinement of the Product Backlog.
Create a graph that plots estimated work remaining in the Sprint against the amount of time remaining in the time box. Plot the Sprint’s progress as a trend line on the graph so that its slope gives an immediately obvious and intuitive indicator as to likelihood of the Development Team meeting its target. The graph should be posted where all Scrum Team members have easy access to it. Update it regularly, at least on a daily basis.
This graph is called a Sprint Burndown Chart, or Sprint Burndown Graph.
The concept of the Sprint Burndown Chart is an analogy drawn from the experiences of pilots trying to land high performance fighter aircraft. It is designed to detect when the plane is high on the glide path. It also shows distance to the end of the runway, rate of descent, and is an indirect indication of airspeed and direction. When the plane is high on the glide path it is often necessary to abort the landing. If the pilot tries to drop more quickly by pulling the nose up and reducing power he or she can get behind the power curve, where going slower requires more power and causes a crash. (This is analogous to Brooks’ Law  that says adding people to a late project makes it later). However, if the problem is detected early enough a good pilot can take safe and effective action to land the plane on the end of the runway. Poor pilots may try to land anyway and touch down beyond the end of the runway. On an aircraft carrier this can destroy the airplane and often the pilot.
In a Sprint Burndown Chart the overall effort estimated to achieve the forecast is stacked on the Y-axis of the graph. The unit of measurement should be the same as used to estimate the PBIs (i.e., Estimation Points).
The amount of time left in working days is shown on the x-axis. This can be represented by a countdown of working days to 0 (the last day of the Sprint), or by calendar dates (i.e., January 4, March 5 etc.).
The Development Team owns the Sprint Burndown Chart. It is a tool originally intended for use by the Development Team rather than by external stakeholders — management included. However, in popular use it has been found useful as an Information Radiator that gives a wider audience transparency into what is happening inside the Production Episode: there is no need to hide anything in Scrum, and transparency can sometimes lead to early impediment detection and resolution. But it is there primarily to help the team manage itself, rather than to provide information to any other party managing development.
Where it has been agreed to use a Sprint Burndown Chart, the ScrumMaster may need to remind the Development Team to update it regularly, and to lead the team towards choosing a format that most clearly and easily expresses its intent.
As work items are completed, the overall amount of work remaining is decremented, and the new total is plotted on the graph. There is a strong benefit in creating the chart on a wall, as a hand-drawn poster, rather than outsourcing it to a tool. On the one hand the Development Team’s sense of ownership is strengthened through the physical act of drawing the trend line, and on the other there is a pressure to keep it simple, focusing on only the essential information the Development Team needs. A wall poster is not easily hidden, either purposefully or by accident. The Sprint Burndown Chart becomes a powerful tool for reinforcing self-management in these circumstances. You can also easily annotate the Sprint Burndown Chart with important events and use those data during the Sprint Retrospective.
It is the estimated work for completed items that are marked off, rather than the actual expended effort. Update the Sprint Burndown Chart in only two cases: reducing the amount of remaining known work if the task is Done; and increasing the amount of known work if the task grows in size due to emergent requirements or other insights gained during the Sprint. Do not reduce the amount of remaining work if a task is only partially completed. The job of the Sprint Burndown Chart is to focus the team forward on what still needs to be done in the days left in the Sprint rather than looking back to the past, however recent. The accuracy of the estimate for any given item does not normally affect the estimates for the remaining items.
An average trend line going from the top of the y-axis (effort) to the right-most calibration mark of the x-axis (time) is often used. The trend line of the Sprint’s actual progress, drawn on the same chart, can then be compared against it. If the team finds its progress is significantly above the average burndown rate, then it may conclude that it is overcommitted and likely to fail the Sprint. If, on the other hand, it is significantly below the average trend line, the Development Team may conclude it has spare capacity in the Sprint.
✥ ✥ ✥
Some Development Teams use graphs that show the effort needed to complete tasks rather than PBIs and some use a “double y-axis” with both PBIs and tasks shown, with a different colored trend line for each on the same Burndown Chart.
The Development Team is free to choose whatever representation suits its needs best, but it should be realized that most often not all the development tasks are known at the end of Sprint Planning. New ones are discovered as more is learned during the Sprint, meaning the overall estimate of work must be raised. Such changes are not easily accommodated in Burndown Charts, and task-focused ones may need to be replaced mid-Sprint, somewhat reducing their usefulness to the Development Team. Moreover, it is possible for the Development Team to have completed a great number of tasks without actually delivering much value.
This should never be true of PBIs, assuming no new ones are allowed to enter the Sprint (unless the Sprint Goal has already been achieved). Since the PBIs represent the essential value propositions of the Sprint Goal the trend line on a Sprint Burndown Chart which focuses on the effort estimated to develop the PBIs keeps the team centered on its delivery of business value.
Ken Schwaber was the first to describe the Sprint Burndown Chart in May 2001. He invented it during his period at Fidelity Investments. 
 Fred Brooks. The Mythical Man Month. Reading, MA.: Addison Wesley, 1975 and 1995.
 Ken Schwaber. “Sprint Burndown.” Web.archive.org, http://web.archive.org/web/20010503112119/www.controlchaos.com/sburndown.htm, May 2001 (accessed 2 November 2017).
Photo credits: USS Coral Sea, Philip West, 1972, Image id: 2342, http://www.usscoralsea.net/images/awf41972.jpg.