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 Burn-Down 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 chart, 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
Advertisement
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 habit a 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 get completed 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 emphasize the importance of tracking completed stories as a measurement of business value delivered for each sprint.[4] Completed stories are 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 "burn-up" chart, and is suggested as a measure of scope change within a sprint.[5] Additionally, it indicates 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 provides direct measurement of 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 a simple, 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 daily stand up meetings to synchronize and focus on 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 "Agile-V" 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 then present 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 "divide and conquer" anti-pattern is not being implemented (see Figure 2).
Figure 2: Agile-V Scorecard that results from the "Divide and Conquer" 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 of applying 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 a powerful 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 fundamental principle 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.
About the Author
Guy Beaver is the Director of Software Engineering at Critical Point Group, a financial services technology firm, and a Certified ScrumMaster Practicing. Prior to that he spent over seven years at Vanguard, where he successfully introduced Agile to a mature waterfall IT organization. His recent experiences include rapid delivery of enterprise Web applications and leading the change to Agile in a large financial services IT shop. He has over 22 years of software engineering and IT experience in several industries including DoD, NASA, and Financial Services.
[1] Balanced Scorecard: Translating Strategy into Action, by Robert S. Kaplan & David P. Norton.
I dropped the use of the traditional Scrum Task Burndown chart some years back when I found (as the author here points out) that it provides a false sense of progress. Both the PO and the Team should always be focusing on business value, not on tasks completed or part-completed. Stories indicate delivered business value, and whether you burn up or down the 'Story Progress' chart is the one true useful sprint progress chart in Scrum.
For those teams using taskboards the board itself shows very clearly the progress of tasks, which after all is only of interest to the team members themselves; I would be wary of making Task Burndowns public beyond the team room, in any form, for all the reasons given here.
1
January 29, 2008
Animikh Sen: ...
Guy, I think you have summarized the concept and importance of the score card really well. I is a lot of potential for this in a distributed agile team, where co-location is not possible. This could serve as a information conduit. What you are assuming is that stories are "well written" here.. I know its a pain for organizations entrenched in "the system shall statements"
2
March 28, 2007
Amr Elssamadisy: ...
Simple idea. I can see how this might be a useful suggestion to those who don't want to use a story board as an information radiator.
3
March 15, 2007
gmbeaver: ...
Adail:
Great comment, and I agree with your opinion of David Anderson's book (Agile Management). It is on my recommended reading list as well, and it is a great reference for understanding the Theory of Constraints in the context of Agile.
I'd like to emphasize the subtle (but important) difference between the Cumulative Flow Diagram and the use of the burn-up chart described in this article. The CFD is tracked over the life of the entire product backlog (weeks), while the burn-up chart is kept tightly synchronized with the burn-down (days in current sprint/iteration).
I don't want to downplay the importance of the CFD at all, but instead bring some attention to the tracking of "business value completed" during the current sprint as a direct measurement of team focus.
Guy
4
March 15, 2007
Adail - www.heptagon.com.br: ...
The so called "Burn Up" chart has been used by FDD (Feature-Driven Development) since 1997, but in a more complete form called Cumulative Flow Diagram (CFD), depicting in the same chart the # of features not initiated (inventory), # of features initiated but not completed (work in progress), and # of features completed (finished work), for each week. David Anderson, in his book "Agile Management", explains it in much detail. It is really a must!
5
March 13, 2007
Doug Shimp: ...
Greatd article! Guy has established background in large organizations and agile adoption. This article summarized some very hard fought for knowledge. - Doug www.3back.com
Articles 
