Viewing Data By Day
At this point, I felt that my Scrum toolbox was nearly complete, but I still needed a slightly different view of the summary data for a particular day or feature. It's critical that you approach this next bit of tooling with the appropriate mindset. Scrum is about team progress on a committed feature set. This next bit of Excel functionality would enable you to pull out performance information about individuals. If you, the Scrum Master, collect and report this information and it is subsequently misused, the loss of trust between you and the other team members will undermine your effectiveness as the Scrum Master. Scrum teams are most successful when they are self-managing and self-organizing teams. The Scrum Master must support and respect these goals, or Scrum will fail.
If you use the tools presented here to punish team members for inaccurate estimates, it will simply cause them to pad their estimates in the future. So be careful not to create a dynamic that leads to estimate padding, or you'll never get a clear report of what the team truly believes the required effort is to get the work done. There are agile techniques for adding buffers to estimates, but adding buffers is beyond the scope of this article. If you're interested in these techniques please check out Mike Cohn's book noted in the resources section.
|Figure 5. Pivot Table: This pivot table shows how work progress toward various tasks looks on a given day.|
With that said, it didn't seem to violate Scrum's tenets to try to get some specific insight into which projects are burning down in the desired direction, and which aren't. The earlier you can gain some insight into features that are struggling, the better you'll be able to get the team the assistance they need and mitigate other risks. In the worst-case scenario, if you can sense that a feature is in trouble early, then you can alert management and do some damage control to protect the team from being asked to perform the impossible, or sacrifice their work-life balance for the remainder of the sprint.
To gain this added insight I set up a couple of native Excel pivot tables to provide insight into the daily burndown information. Figure 5
shows an example.
I set up the pivot tables and charting to show how the work stacked up at the start of the sprint. Each day I modify a similar table and chart by its side on the same worksheet that shows how things look on that particular day. You can see these tables and charts on the Report Summary page in the sample spreadsheet.
|Figure 6. Single-feature View: Using a pivot table, you can narrow the burndown view to a single task. This view has lines for both development and quality assurance.|
Finally, I supplemented the chart in Figure 5
with another pivot table that lets me see the burndown for a particular feature (see Figure 6
). The power of the pivot table is that it enables you to make selections and essentially 'pivot' the data around different variables. Using this technique you can pull information out of the burndown and narrow the view to one feature.
The graph in Figure 6 points out some of the process dysfunctions quite clearly. In real life, this feature was transferred from one developer to another, leading to considerable churn about requirements that caused a very bumpy ride. Moreover, this graph view shows that the testing effort has scarcely been started.
The Scrum process is ideally suited to provide near real-time insights into what is truly going on in your development process. Having powerful analysis and reporting tools at your disposal will make your job easier and allow you to support your team's efforts more effectively. Moreover, the ability to gain earlier awareness of possible problems will improve your ability to communicate about your team's progress and challenges.