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 stories. Worst of all, the same amount of team energy has been spent on the lowest priority stories as the highest value stories. This anti-pattern is a productivity killer and needs quick exposure. A properly prioritized backlog that is worked down in priority order guarantees that the team's energy is focused on closing stories that create the most value for the client. Can this intangible team focus be measured in the Balanced Scorecard sense so that it is visible, motivating, and directly linked to business value?
There are articles in Agile literature that emphasizethe importance of tracking completed stories as a measurement of business value delivered for each sprint.[4] Completed storiesare an extremely valuable metric and provide great visibility to the business value delivered with each sprint for the project duration.
The Burn-Up Chart(Stories Completed)
The measurement of stories completed during a sprint has been called a quot;burn-upquot; chart, and is suggested as a measure of scope change within a sprint.[5] Additionally, itindicates business value delivered and tracks progress towards release to the customer. Story burn-up shows business value created, but also shows cycle time of that business value released to the customer. The value of this chart should not be overlooked, as it also providesdirect measurementof how well team focus is being applied to incrementally complete stories during a sprint.
Consider tracking the burn-down chart along with the burn-up chart,especially with a new Scrum team. Without it, there is no measure of team focus. The burn-down combined with the burn-up provides asimple, powerful and accurate "Driver and Outcome" scorecard. By focusing on both, the team is provided an Agile Scorecard that shows both capacity utilization and team focus. If time passes with no stories completed, the team should ensure that it is utilizing the dailystand up meetingstosynchronize and focuson as few stories as possible, so that business client priorities can be worked to completion in the correct order. The ideal burn-down and burn-up charts, paired side-by-side resemble a "V" hence the name "Agile-V Scorecard" (see Figure 1).
Figure 1: Ideal burn-down (effort remaining)and burn-up (stories completed) charts. Together, they form the quot;Agile-Vquot; Scorecard.
In reality, the burn-up chart does not track a straight line,nor should it be expected to.Consider the first sprint in a project, where necessary energy and focus might be spent on getting environments and tools set up prior to closing business value stories. In general, stories are usually completed in chunks, which thenpresent as "steps" in a burn-up chart. If more than one or two days pass without an increase in stories completed, a mature Agile team will quickly focus on impediments to completing stories. This could be due to dependencies, but the properly established Agile team looks to re-focus during the daily Scrum in order ensure that the quot;divide and conquerquot; anti-pattern is not being implemented (see Figure 2).
Figure 2: Agile-V Scorecard that results from the quot;Divide and Conquerquot; anti-pattern. Note that the burn-down appears successful through 75% of the sprint; however the burn-up chart indicates problems much sooner (stalled story completion).
There are great examples of burn-down patterns describing common behaviors that drive the way burn-down charts progress.[6] However, be very wary ofapplying statistical analysis to the burn-up chart in order to "predict" the success of a sprint. This is unnecessary and a waste of time, since sprints are of such short duration. The real information behind the current burn-up chart should be readily available to a seasoned Agile manager who can recognize story velocity by means of visible inspection of story and task status shown on an information radiator.[7] Stories and tasks on the information radiator should make visible the order in which they are being worked, as well as serve as the center of focus during the daily Scrum. Team members should be encouraged to physically touch the stories and tasks on which they are working, and be restrained from moving to new stories until a reasonable chunk are completed.
Finally, in the spirit of keeping Agile light, adding burn-up to the burn-down to form the Agile-V Scorecard is suggested, not required. A well-established Agile team that understands the importance of delivering value with each sprint will naturally focus on priorities. For organizations new to Agile, the Agile-V provides a daily measure of the team's focus on delivering prioritized business value. This daily feedback helps establish the proper rhythm and pace that are intangible signs of a mature Agile team.
Summary
The Agile-V Scorecard provides a clear snapshot of effort remaining (burn-down) and business value completed (burn-up). By itself, the burn-down chart provides a clear view of effort remaining, but it can potentially hide how well the team is focusing on incremental completion of business value. Pairing the two charts provides apowerful driver-output pair. Since the burn-down is a direct measure of work driving the current sprint, and the burn-up is a direct measure of business goals, the Agile-V scorecard provides a tightly linked, tightly controlled, direct line-of-site to business value. Using the Agile-V Scorecard ensures that most important work is focused on and completed as soon as possible. This will naturally result in the implementation of a fundamentalprinciple of Agile -- don't build what you don't need.
Acknowledgements
The author is grateful to Alan Chedalawada at NetObjectives and Doug Shimp at 3Back for helpful and enlightening discussions on team focus and validation-centric processes.
[1] Balanced Scorecard: Translating Strategy into Action, by Robert S. Kaplanamp; David P. Norton.
[2] "How to Use the Balanced Scorecard" www.cio.com
[3] Calculating Earned Business Value For An Agile Project Dan Rawsthorne
[4] see "Metrics for Agile Development Projects" by Liz Barnett, Carol Schwaber, amp; Lindsey Hogan, and "Metrics for Application Development" by Liz Barnett, Margo Visitacion, Mike Gilpin, amp; Craig Symons
[5] "Big Visible Charts" by Ron Jeffries
6] "Seven common Sprint Burndown graph signatures" Kane Mar, http://kanemar.wordpress.com/2006/11/07/seven-common-sprint-burndown-graph-signatures
[7] "Information Radiator" Alistair Cockburn
