By Rivi Aspler
Agile teams rely on a prioritized backlog to guide their work. Ideally, when your product owner defines a product backlog item, he or she should focus on its value to your customer. That’s the school instruction. In practice, the product owner will actually consider the following:
- Business Value
- Known Obligations to Customers
- R&D Effort Estimation
- Dependency on other Backlog Items
Business Value
‘Business Value’ should be the main driver for the Backlog Prioritization. If your backlog is well prioritized, your sales people would find it easier to sell the product, since it really brings, money-worth, value to the buying organization.
Furthermore, your backlog should consist of features that bring value to your Target / Strategic Customers, hence maximizing the chances to win large tenders.
But, life isn’t that straight forward and as a product owner, you will often find yourself prioritizing your backlog using more than the Business Value parameter.
Known Obligations to Customers
Ideally, obligated backlog items should also be the ones that bring most business value. Unfortunately this is not always the case.
This is the reason that product owners love and hate these obligations.
On the one hand, these off-target obligations contaminate their ideal product backlog with sales people promises to customers.
On the other hand, these known obligations mean that the product is out there in the field and that customers want it as long as feature A is in.
R&D Effort Estimation
Just like in real-life, ‘buying’ features from R&D you will often buy a few cost-effective items rather than one expensive feature. The example below shows such a case.
Naturally, you would rather do that with backlog items that are similarly prioritized and not invest the precious R&D time in many cheap features that are totally nice-to-have.
Dependency on other Backlog Items
Guiding product owners to break requirements into the littlest user stories, R&D is often presented with a list of user stories that each has its own business value but that technically have many cross dependencies.
In such a case R&D would present to the product owner a constraint of cross-dependencies which in turn affect the user stories grouping and hence, the product backlog prioritization.
As one can see, all of the above are known constraints that push that business value aside a bit, making it defacto, a less important than wanted parameter. Your job as a product owner is first of all to be aware of that and secondly, try to minimize the effect of the non business considerations.
Rivi
Tweet this: How Important (really) is Business Value to your Backlog Prioritization? http://wp.me/pXBON-3Gr #prodmgmt #agile