The burn-down has exploded in popularity as a tool for tracking the team's activities, in part because The Scrum Guide
uses broad language in the section titled "Monitoring Progress Toward a Goal." However, I have found quite a few misuses of burn-downs.
Project structures that affect choice of metrics
I try to use burn-downs as an example to come up with a rule of thumb for determining which metrics can be used for a specific purpose. But first let’s take a look at a couple of ways in which projects and teams may be structured within an organization that can influence your choice of metrics.
Scenario 1: All sprint items are from the same project
- Burn-down may have work items for the project and maybe even include some internal team initiatives.
- The sprint burn-down may be based on tasks and hours updates.
Scenario 2: Sprint items are from multiple projects
- This scenario happens when an existing software system needs to make changes for incoming projects.
- The sprint burn-down may be based on tasks and hours.
We should be clear about identifying and using the appropriate metric for the activity or process we want to measure. People perform to metrics, and the incorrect use of a metric can kill agility in a hurry. Project management operates by using hour estimates and costs. It's likely that they could start tracking hour estimates on tasks inside a sprint. This approach has two negative effects:
- The project management office (PMO) could enforce the updating and tracking of hours burned, which will roll back any hopes of an empowered or self-managed team.
- If there are stories from more than one source in the sprint, then the burn-down will paint an incorrect picture of the project progress. The burn-down actually contains information about all items in the sprint, not just items from the project in focus.
This underscores the wider concern about the appropriate use of Scrum metrics. The team works within an ecosystem and organizational hierarchies. Transparency is a good thing, but it should come with the knowledge of using the correct metrics.
The wider question of Scrum metrics
Agile principles say it best: "Working software is the primary measure of progress." A project in Scrum is a set of features to be delivered. It’s not a set of activities to be completed and not a set of hours to be burned. To state it simply, a project is a set of epics or stories. Working software
is the collection of stories for which the team has successfully completed the demo. Therefore, the progress of a project is the percentage of stories with a successful demo. Tracking hours is counterproductive.
Project burn-down can be used to track the progress of the project, whereas the sprint burn-down is for internal consumption by the team. It helps the team retrospect on how the sprint execution went. It can reveal how disciplined the team is.
A rule that works reasonably well
The question of hours and cost
In many organizations, the ecosystem does not automatically switch to story points just because IT has moved to Scrum. Projects and budgets still work in dollars, and the PMO still wants to track hours.
Let's work with an example that illustrates this point. Assume that a team of eight people has completed 124 story points in the last three sprints. The numbers look something like this:
The team completes 124 points in 3 (sprints) X 10 (days) X 8 (hours) = 240 hrs.
Or if represented as points: 240/124 = 1.93 hours/story point
For high-level calculations, you can use a multiplying factor to go from story point to hours and then to cost.
What we measure provides direction for the organization. High transparency and data availability can be used to micromanage, which will destroy team empowerment and, with it, the souls of Scrum teams. Use Agile principles to guide you on how to measure a team and its progress. Remember that "working software is the primary measure of progress."