Get certified - Transform your world of work today

Close

Metrics, Burndowns, and Their Uses in Scrum

Putting the right metric to the correct use

19 April 2017

Anurag Prakash
Blue Cross Blue Shield


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.


Using burn-downs

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:
  1. 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.
  2. 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.
 

Conclusion

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."
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Swarna Jayaraman, CSM, 4/24/2017 10:30:12 AM
Neatly written article. The rule given for Data sources inside and outside sprint is represented in a beautiful way. I can realise the chaos it makes when the data is shared at inappropriate level. Thank you!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe