InfoQ

News

Prioritizing (the Backlog) For Profit

Posted by Derek Longmuir on Aug 08, 2008 02:49 PM

Community
Agile
Topics
Customers & Requirements
Tags
Planning ,
Scrum ,
agile2008 ,
Complementary Practices

Having difficulty prioritizing the backlog? Luke Hohmann has described a method to make quantitative decisions about what backlog items should be considered first. In addition to the usual attributes such as implementation effort, Luke suggested adding attributes to measure the stakeholders needs, strategic alignment and to ask if the item is driving profit or not.

Luke outlined the following approach at Agile 2008 this week. Here is a summary from his presentation:

Select Prioritization Attributes

Decide on a set of attributes that will be useful when ordering the backlog items. An assessment of the cost required to determine the score of the attribute is also needed – it might be high cost to acquire the data required to score an attribute (such as doing brand new market research), which would need to be balanced against the benefit that scoring that attribute would provide to this process.

Group the related attributes so that similar attributes can be thought of together. Luke suggests three groupings that help focus on the business value of each item in the backlog:

  1. Stakeholder Alignment (“who needs this done?”)
  2. Strategic Alignment (“why are we doing this?”)
  3. Driving Profit (“will this result in money or reduced costs?”)

Stakeholder alignment is a list of the project’s stakeholders (internal and external), one attribute per stakeholder. Examples are sales, legal, customers, operations, development, and “the system”. “The system” represents the program itself, which would have a stake in backlog items representing program improvements such as technical debt items and the upgrading of any frameworks.

For strategic alignment the product manager may need to look to the strategy for the product being produced, including divisional and/or corporate goals that may have been set by the executive team. Luke uses the example of a company that had strategic goals that distilled down to being the attributes of “global”, “social” and “mobile”.

The driving profit attributes represent how the product produces money and what relationship the backlog item has to it. At the simplest, it may be attributes for “increases revenue” and “decreases costs”.

Anything that the ranking decision is being based on should be an attribute so that the ranking process is transparent. Some other things that could be attributes are: if the item is needed to meet regulatory compliance requirements, if there is some sales driver, if it will help with time to market, and even an attribute representing something like “must have for next release”.

Determine Weighting of Each Attribute

Assign each attribute a weighting representing how important the attribute is relative to the other attributes.

These weightings can and should change as the product evolves. Anytime planning is being done the weights should be re-evaluated. Different stakeholders will have different weightings based on the stage of the development. At the start, the sales and customer stakeholders might be weighted higher than the operations stakeholder so that new features are higher priority on the backlog. Later iterations (presumably closer to the release) may put a focus on deployment and operations, resulting in increasing the operations stakeholder weighting and reducing the sales and customer weightings. This will cause the operations backlog items to be higher priority on the backlog.

Score Attributes

Go through each backlog item asking a yes/no question for each attribute in the list. For example, ask each stakeholder representative “Will this item help with your work?”. Luke notes that if the answers are all the same for one attribute and therefore you aren’t getting any ranking information from that attribute you should go back and change that attribute. Splitting an attribute into two or more attributes might better represent different viewpoints on the backlog item, or you might find that elimination of the attribute makes the most sense.

For each “yes” that an attribute receives, add the weight of that attribute to the total score for that backlog item. You will then end up with a score for each item that aggregates all the attribute scores.

Sort Backlog Items

The final step is to sort the backlog items by their scores and do schedule (iteration, release) planning. Luke suggests that each stakeholder gets at least one of their items included and that each item that is selected for work also has at least one “yes” in one of the strategic alignment group of attributes as well as at least one “yes” in the profit group. This produces a balanced backlog of work that should keep everyone happy and committed to.

In his presentation at Agile 2008, Luke showed a sample spreadsheet for backlog prioritization. Luke expects to post it soon on his website, where you can also find other posts on this topic and additional tools and ideas to further refine your backlog prioritization, and help if you get stuck.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

No comments

Watch Thread Reply

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.