he purpose of Scrum is to help build great software through empirical process control. A healthy emphasis on continuous process improvement works naturally with Scrum because Scrum evolved from applying Lean-Agile manufacturing techniques to software development. The article describes some Excel tools I developed to help manage teams that can help you examine your implementation of the Scrum process in more depth.

You'll find a free sample workbook illustrating these tools that you can experiment with in the downloadable code that accompanies this article and step-by-step instructions in the sidebar How-To to run the code.

Teams using Scrum need to thoroughly understand its effects on their development cycle. They need reliable measures of throughput and visibility into where team members' non-sprint time is being spent. Therefore, the main thrust of the VBA-generated reports and Excel pivot tables described in this article is to enhance the visibility of what is really going on in the development process so you can produce better software faster. Knowing what is really going on is the only way to improve your process.

Figure 1. Burndown Graph: Here's an ideal line superimposed over the actual work completion rate line.

The essential metric of the Scrum process is the daily burndown graph, which shows the estimated work remaining for a task or set of tasks day by day. Ideally, a burndown graph should have a downward trend; in other words, you'd like to see that the team completes a day's worth of the remaining work each day. That doesn't always happen in practice. For example, the burndown graph in Figure 1 shows an ideal line superimposed over the actual work completion rate line.

Figure 1 shows how work was loaded and started to burndown for a 20-day sprint. The initial value of 15 days (work remaining) was calculated by dividing the total number of hours of estimated work by the ideal number of hours of project work a person can complete in a day (five is reasonable), multiplied by the number of people on the team:

   Total estimated hours / (ideal hours per day * 
      number of team members)

In Figure 1, the sudden rise in the estimate of remaining work on day three suggests that the team missed a chunk of hours in the initial task at the iteration planning session. It is critical to remember that an estimate is just that—an estimate—and in agile development it is perfectly acceptable for estimates to change, new tasks to be added, or unneeded tasks removed. It is crucial for the Scrum Master to foster an atmosphere that values honest estimates, without punishing team members for overestimating or underestimating. Again, estimates will always be estimates—not guaranteed future results.