At Agile 2008, Luke Hohmann from Enthiosys talked about converting business value into actual money. Luke said prioritizing the backlog by ROI doesn’t work and suggested developing attributes for backlog prioritization that drive profitable growth. In terms of what we’ve been doing at one of our clients using throughput accounting this means increasing revenue without significantly increasing investment and decreasing costs without impacting throughput (or the capacity to deliver).
Luke explained that to effectively prioritize the backlog for profit a set of attributes should be identified for the stories in it. A weight is assigned to each attribute representing the degree of influence the attribute has. A 1 or a 0 is assigned to the attribute, which is multiplied by the weight. Using binary numbers activates the weight rather than amplifies it. The backlog is sorted by the resulting numbers. Attributes can be broadly grouped as follows (there may be others):
1. Stakeholder Preferences
Internal stakeholders might be sales, marketing, customer service. And, of course, the product or ‘system’ itself because it has its own needs (repayment of debt, performance, maintenance, etc) and should therefore have its own voice to encourage continuous investment in its architecture and upkeep. External stakeholders might be customers, integration and/or development partners, distributors. Obtain stakeholder preferences by leveraging attribute weighting and collaborative innovation games to enable continuous prioritization of the backlog.
2. Strategic Alignment
The backlog must support the larger corporate and portfolio goals. Associate corporate strategy attributes to the backlog and identify which stories directly support the strategy.
3. Driving Profit
The business model for driving profit comprises a value exchange model and a profit engine. The value exchange model defines the mechanism by which value is converted to money. Here are some value exchange models:
- Time-based access: Revenue earned by granting the right to use the product for a defined period of time, e.g. licensing, rental, subscription.
- Transaction: Revenue earned by charging for completion of units of work, e.g. completing a credit card payment on behalf of the card holder.
- Meter: Revenue earned by constraining the use of the product, e.g. the number of concurrent users or pay-as-you-go mobile phone cards.
- Percentage of revenue gained (or costs saved): Revenue earned by taking a cut of the profit, e.g. a royalty payment.
- Hardware: Revenue earned by charging an amount for the hardware required to use the software, e.g. dongles.
- Service: Revenue earned by providing a service, e.g. technical support, upgrades.
- Data or Content: Revenue earned by creating unique data and charging for access to it.
The profit engine defines how the product’s relationship with the market is structured to drive increasing exchanges of value. E.g. credit card provider networks are widely available and card providers drive common standards (for the card and card readers) to lower costs and offer additional services such as anti-fraud to drive transactions.
A prioritized backlog should be consistent with the product’s value exchange model and profit engine. It should be possible to identify the stories that contribute to driving profit, e.g if a product’s value exchange model is transactional then a story aimed at reducing processing time per transaction could assist profit by lowering operational costs. A prioritized backlog should also balance stakeholder demands and be strategically aligned with the portfolio and corporate strategy. So, each iteration should convert value into money by delivering something that generates revenue and grows profit. Every stakeholder should receive something that demonstrably satisfies their needs and the product, portfolio and corporate goals.
2 Comments
Hi Simon
I'm curious. How often to you reevaluate the "business model" that you have built up? One of the things I have found is that the business rationale for the project changes (sometimes alarmingly frequently). Markets change, assumptions are invalidated, competitor launch disruption technology, etc.
Also how much energy goes into creating the model?
I also like having models like these (although I'm not so prescriptive in the form that they take). I tend to prefer a more lightweight pull approach (kanbanesque) and use the model as a litmus test to see if a story makes sense or not.
Hi Andy
Actually I've not used the model above. My post is just a write-up of my notes from Luke Hohman's session.
I'm interested in the idea of capturing stakeholder's needs and weighting to see how this actually helps to prioritize for profit. We're currently driving profit by chasing page impressions - our revenue comes from adverts – and we use throughput accounting to manage operating expenses (and avoid inventory).
The model does seem a bit heavy to me and I'm thinking, as it stands, it could be done a quarterly basis, which would suit our incremental funding cycle. But I want to experiment to see if the model can be made lighter so that it can be done on a monthly basis, which would suit our strategic planning game cycle with the Product Sponsor where we set our targets to pursue over the next month (typically 4 1-week iterations).