The Agile-V Balanced Scorecard Metrics

[article]
Summary:

Much has been written about the balanced scorecard methodology. Its goal is to measure desired outcomes and predict drivers of those outcomes. For a properly implemented agile team, this line-of-site measurement happens naturally and is controlled daily. This article suggests a simple and natural scorecard that provides accurate daily visibility of drivers and outcomes for an agile team focused on delivering business value to its clients.

Much has been written about the balanced scorecard methodology. Its goal is to measure desired outcomes and predict drivers of those outcomes. [1, 2] A fundamental premise is that measuring what you want to achieve helps motivate its implementation. Large-scale implementations of the balanced scorecard link individual processes to overall business goals. For a properly implemented agile team, this line-of-site measurement happens naturally and is controlled daily. This article suggests a simple and natural scorecard that provides accurate daily visibility of drivers and outcomes for an agile team focused on delivering business value to its clients. With its emphasis on business value (as opposed to deliverable status), this scorecard offers a powerful approach to providing daily readout to management on the progress of agile projects as they are piloted in a waterfall organization.

The Burndown Chart: Enough?
One of the three standard Scrum artifacts is the infamous burn-down chart, which tracks remaining effort. Updated daily, it presents a picture of tight control over progress of the current iteration or sprint. Scrum teams implemented correctly soon realize that the accuracy and value of this artifact far exceeds that of a typical Gantt chart, with its best-practice minimum task size of two weeks. Once initiated to the value of burn-down charts, upper management and product owners quickly learn to trust this measurement to provide accurate status. But is the burn-down chart all that is required to inspect the daily status of the project?

While the burn-down chart tightly {sidebar id=1} tracks the daily status of an agile team's capacity, there is no guarantee that the full team focus is being leveraged daily to deliver prioritized business value. For new agile teams, this can be a difficult quality to implement and is not tracked in the burn-down chart. A possible solution is described below.

In agile, business value is measured by various methods. Typically discussed and accepted units are story points, features, or user stories. For this article, the focus is on "user stories" or simply "stories" to quantify individual pieces of business value delivered in a sprint. The team estimates effort for stories by breaking them into tasks, and a story is "done" when all the tasks required to implement the story are done (in the agile sense, done means production ready with all acceptance tests completed and automated). Stories created by the product owner define the business value that the agile team implements. There are also technical implementation and business implementation stories that are required, but offer no business value. Techniques have been described in the literature to assign business value to a work breakdown structure based on business and non-business stories. [3]

Agile Anti-Pattern: Divide and Conquer
A difficult habita new Agile team must unlearn is the "divide and conquer" approach. It is not unexpected for a seasoned waterfall project manager new to Agile to look at a backlog of stories and assign them out among team members.This Agile anti-pattern discourages collaboration and encourages individuals to work alone on their assigned stories and tasks. In the worst case scenario,most tasks getcompleted for all stories, but no stories get completely "done" and delivered to the product owner. This behavior can be hidden in a burn-down chart that successfully burns down remaining effort, while individuals are spreading their energy across all the stories and tasks in the current backlog.

Imagine the new Agile team that completes all tasks for each story except final system test until the last few days of the sprint, when the System Tester starts to scream that there is not enough time to complete testing for all the

About the author

Guy Beaver's picture Guy Beaver

Guy Beaver is the CIO at Perfect Commerce, a software company that provides SaaS procurement solutions for large corporations. At Perfect Commerce, he leads and oversees the development, delivery and support of all Information Technology. Guy's career of over 25 years spans several industries including Aerospace, Financial Services, Healthcare, and Procurement. He co-authored the book, Lean-Agile Software Development: Achieving Enterprise Agility.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03