InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Prioritizing (the Backlog) For Profit

Posted by Derek Longmuir on Aug 08, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Customers & Requirements ,
Agile
Tags
Planning ,
agile2008 ,
Scrum ,
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.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

No comments

Watch Thread Reply

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.