Product-Backlog-Charts and Sprint-Backlog-Charts are used in almost all Agile approaches. In the following article the terminology of SCRUM is used, e.g. User Stories, Product Owner, Product Backlog, Sprint and Sprint Planning Meeting.
The described Backlog-Charts are also useful in other agile methodologies and even in non-agile settings. Actually, they are a general technique to estimate efforts in situations where other estimation methods are difficult to apply and/or when historical data are not yet available.
Product-Burndown-Chart
A Product-Burndown-Chart depicts story points of all user stories in the so called product backlog, where the product backlog is a simple ranked list of all functional and non-functional requirements described as user stories. The chart displays story points for each completed sprint, so it depicts the completion of requirements over time. Backlog and Product-Burndown-Chart is usually updated at the end of each sprint. New user stories can be added and/or removed before each sprint planning meeting.
Figure 1: Sample Product-Burndown-Chart
A simplified Product-Burndown-Chart is shown in Figure 1. Here the team had a constant velocity of 50 story points per sprint. In the second sprint some user stories (with 100 story points) had been added and in the fifth sprint some user stories (100 story points) have been removed. The sprint with the number zero is just used to show the initial backlog value before the first sprint (Table 1 contains the raw data of the graph).
Table 1: Data of Product Burndown-Chart-Sample
| Sprint | Remaining | New | Removed | Done |
| 0 | 600 | 0 | 0 | -50 |
| 1 | 550 | 0 | 0 | -50 |
| 2 | 500 | 100 | 0 | -50 |
| 3 | 550 | 0 | 0 | -50 |
| 4 | 500 | 0 | 0 | -50 |
| 5 | 450 | 0 | -100 | -50 |
| 6 | 300 | 0 | 0 | -50 |
| 7 | 250 | 0 | 0 | -50 |
| 8 | 200 | 0 | 0 | -50 |
Sometimes it makes sense, to use instead of story points a simpler measure for complexity of tasks. This can be an enumeration like {large, medium, small} which can be mapped in the backlog to numbers. This can be useful for maintenance and/or operations teams. The important point is that a relative complexity measure is available and used for estimation.
The purpose of the Product-Burndown-Chart is to show the team and stakeholders how many sprints will be needed to implement all remaining user stories or how many user stories can be completed in the remaining time.
After some User Stories have been completed, the needed working hours for the related tasks can be summed up and divided by the story points. That gives the velocity of the team, which can be used to improve the planning quality.
Sprint-Burndown-Chart
A Sprint-Burndown-Chart shows all remaining work of the so called the sprint backlog. This sprint backlog contains all work for the current sprint as committed by the team. Usually it is displayed as remaining work in ideal hours for each work day. The Sprint-Burndown-Chart is updated on a daily basis by the team – often before the stand-up meeting of the next work day.
Figure 2: Sample Sprint-Burndown-Chart
Like in the Product Burndown there is a working day zero to show the initially planned work before the first work day is finished. The purpose of the Sprint-Burndown-Chart is to show the team if all planned tasks can be finished till the end of the sprint.
Reference: How to use Product-Burndown-Charts and Sprint-Burndown-Charts not only in SCRUM Projects? from our JCG partner Markus Sprunck at the Software Engineering Candies blog.
