Prioritizing the Backlog with the Business in Mind

Last night, I went to a talk given by Luke Hohmann of Enthiosys for Agile Austin.

The talk was focused around prioritizing the backlog. A more in depth version will be presented by Luke at the Agile Conference in August. There were a few good points that I took away from it.

The first is that you need to really understand your business. Luke's company has identified 7 different models that companies use to make money in software (they call them Value Exchange Models). These include selling by transaction (ex., a click through on a Google advertisement), by time (ex., support), by metering (ex., # cpu's), by data, by service (ex. a hosted service), by hardware (ex., embedded) or by % of cost saved / revenue gained.

You might blend multiple of these. But you need to understand which you use. And then think about the engines you have in place to drive those. For example, Adobe wouldn't sell many Acrobat editors if the reader wasn't ubiquitous.

Now that you understand the business a little better, identify things that would help to make those more successful and then prioritize your backlog based on how much the item is expected to help.

Google makes its money on transactions (clicks on advertising). If the Gmail team focused just on making the best email software possible, they might not be helping the business at all. Instead, they should focus on how they can make email better at driving users to click on advertising.

Obviously, there's always multiple factors involved / goals you are trying to achieve. Gmail has to remain competitive or it will fail. The key is to focus on the most important few and then to prioritize based on what will help best in achieving those.

Another good point he made was that you should analyze the success of the release in driving those engines. If you thought something would help and it didn't, figure out why not or you're likely to make a similar mistake in the future.

The final point that I took away was that the whole team needs to understand the business engines and how what they're doing will help. If it is restricted to just the product manager, you won't get nearly the benefit. 10 heads are better than one. Particularly when those other 9 are doing things daily which directly impact what you're trying to accomplish.