Progress in Scrum is analyzed within the Sprints using a Burndown Chart. The Burndown Chart provides information on the remaining work to be performed from the current day. Days are plotted on the x-axis and work hours on the y-axis. Each Team Member estimates the remaining effort of his or her tasks every day, therefore resulting in improved accuracy from day to day. From this example, trends and forecasts can be derived to some degree.
Diagram 11: Burndown Chart – Planning Case and Real Case
Diagram 11 illustrates in everyday life the more unrealistic plan case and a more realistic case. In the case of “Real”, the Team initially has a very good performance, better than expected; however, on the 3rd day, it is determined that the effort for certain tasks is significantly higher. On the 4th day the Team still made very good progress and was back on track. On the 5th Day, more work than originally planned emerges; not until the 7th Day can the performance be improved again. Then on the 10th day is the implementation. Based on the experience of Sprint to Sprint, a team’s Performance Index can be created which indicates the velocity. This can be done, for instance, by means of the number of applicable productive work hours per employee – for example, three to five out of eight hours per day.
The following example in Diagram 12 describes a Team which has given up too many tasks:
Diagram 12: Burndown Chart – overextended
It is evident from this Burndown Chart that the estimates of the tasks have not been accurate enough from the start. At the beginning of the work, the effort was estimated higher than planned. After running through the tasks, a relatively linear execution of the tasks is possible from day 3.
The following Diagram 13 illustrates an “Under-commitment”. This means that individual people were or a whole team was not fully utilized during a Sprint. The Burndown Chart shows that the estimation of the tasks was not accurate enough from the start.
Diagram 13: Burndown Chart – Workload too little
The line “too little 2” shows that there has been no progress at first, and then the work was done in a few days. Up to the penetration of the tasks a good estimation for the Team was apparently not possible. Only after was a continuous execution of the tasks possible.
The line “too little” suggests a very large uncertainty about the effort of the tasks that has been covered by the Team in the planning with a large buffer.
Burndown Charts provide more reliable statements about remaining efforts from day-to-day. These are very close to the “real” remaining effort because they are the current estimates of the Development Team. It helps the Team in identifying risks and in the daily planning. It is not the project manager who detects the progress and looks for compliance of the planning – maybe “with the whip in his hand” – but the Team itself.
Again, it is obvious that the entire development stands and falls with the Team. A time planning can no longer go against the Team, but rather only with the Team and on the basis of real progress.
But as with a conventionally managed development project, it naturally stands or falls with those who implement it. A non-motivated or incapable Team cannot achieve peak performance without proper project management. From this perspective, it is logical to grant the Development Team those freedoms and to take advantage of its potential, rather than endangering them with rigid rules.
The motivation of the Team is ensured in the long term through the autonomy and self-organization of the Team. So external circumstances are no longer blamed for the emergence of “Blockers”, but addressed and resolved by the Team itself.