My latest article Bolstering the Backlog was published last week on gantthead.com. In this article I explore how Agile teams can measure business value using a “Results Backlog” in conjunction with the Product Backlog. While not completely spoiling this finely written piece of literary excellence :-), here’s a summary of the main ideas:

There is a distinction between Ends and Means. Ends are where you want to go. Means are actions for how you’ll get there.
Scrum’s Product Backlog is typically (in my experience) used for storing and managing the “means”, such as features, user stories, use cases, etc. There is no artifact in Scrum for storing and managing the “ends”, it is assumed this is done elsewhere, outside Scrum. Again (in my experience), I rarely see “ends” actively managed on a project, a problem I think needs addressing.
While “means” provides a good level of direction for people that have to implement the feature, they don’t provide quite as good information to people making decisions about budget and value for their investment.
I propose using a Results Backlog to manage the “ends” (measurable business objectives) in conjunction with the Product Backlog for managing the “means” (features, user stories). Each has a distinct purpose.

The concepts behind a Results Backlog aren’t new, rather they are time tested and a central part of the Evo method. I’ve been combining Evo and Scrum for a while now. What is new:

Simple Integration with Scrum - The goal was to introduce something new (measurable objectives) with something already familiar (a Backlog) and use it during an existing Scrum process (Release Planning). Minimize the change for existing Scrum teams.
New Artifact - The use of a new term Results Backlog to describe a new artifact that’s one level higher than the Product Backlog. By adding Backlog as suffix, its implied the desired business results should be prioritized. I’m hoping this new concept is easy to understand for someone already familiar with Scrum.
New Responsibility - Assigning the Product Owner as the person responsible for creating and managing the Results Backlog (and accountable for the results). They must work with the Key Stakeholders to prioritize and quantify the business objectives and ensure the team is focused on meeting these objectives during the Release.
Updated Release Planning Process - Before Release Planning, the Product Owner ensures the following activities are completed. I’ve found a combination of 1-on-1 stakeholder interviews plus a 1/2 day work session to get consensus works well to prepare in advance. One or two weeks (duration, not effort) is generally sufficient to get this done on a medium-sized project (it largely depends on stakeholder availability or interviews). For a small project, this can be done in one or two days if everyone is present and focused:
Define and Prioritize Stakeholders - Determine who you are serving and what’s most important to them. Value is not absolute, it is relative to the stakeholder, so ensure you have a clear sense of who you’re serving first.
Identify and Quantify Desired Results - While words like “improve”, “increase” and “reduce” are nice sounding, but they are vague and open to many interpretations. We should be more precise. Quantifying them with numbers allows you to set expectations around the levels of improvement desired (and what’s possible within budget). See my article for a how-to on this topic.
Prioritize Desired Results - Facilitate stakeholders in selecting the few results to focus on initially (top 3 or less). Have key implementation team members present and have them estimate whether the desired target levels are achievable within the proposed resource budget (time and money). If not, negotiate lower target levels with stakeholders, add more resources or re-prioritize objectives. Get consensus on the estimated level of improvement to be achieved in the upcoming release.
Identify Winning Strategies - Challenge the implementation team to identify strategies that deliver results quickly. These strategies could be projects, epic stories or even process improvements - something at a macro level. Use Value Decision Tables to help estimate the potential value delivered and compare alternate strategies and designs (again, using numbers). The strategies with the best performance-to-cost ratio should be pursued first.
Turn Strategies into Requirements - For the chosen strategies in an upcoming release, break down into user stories and prioritize in the Product Backlog for implementation.

From here, Scrum’s Release Planning process takes over for prioritizing stories within the release. At the end of the release, the one additional step is to measure the ‘progress towards the desired results’ - this represents the ‘business value’ of the release as measured in terms the stakeholders have defined. While the number of features delivered can be calculated easily with the Product Backlog, the Results Backlog will maintain the overall progress towards goals.

Since the article was written, I’m starting to use the Results Backlog on projects and will report back on how it goes. If you’d like to try it out, please contact me with your feedback and any issues uncovered putting it into practice. I’m genuinely interested if you find the concept useful enough to put into practice.