Product backlog should be DEEP – detailed appropriately, emergent, estimated and prioritised. Everyone who learns about Scrum should be familiar with these key attributes of a good product backlog.
But how is the product backlog ordered? Well, most Scrum practitioners would probably say that it’s Product Owner’s decision, but the business value seems like a fair attribute to be used for product backlog prioritisation.
While saying so is a good generalisation the reality is, unfortunately, a bit more complex. The reason for this is that a good product backlog consists not only of client-facing stories, but there are also other items like design spikes, technical debt reduction stories, maintenance items, etc. Smart Product Owner knows that she can’t concentrate on business stories only because she’s responsible for long-term product’s adaptability and reliability.
In addition, things like upcoming marketing event may also drive prioritisation and, therefore, short-term value and features of a lower overall value can take precedence over long-term gains.
Furthermore, risk mitigation is also a very important factor that influences how product backlog is ordered. Actual risk reduction is a key objective that the team should concentrate on at the beginning of a complex project. For example, it makes sense to prioritise some technical stories first to check if a technology we want to use is right the project before investing too much money into an endeavour that may eventually fail.
As you can see ordering a product backlog is an act of balancing many different factors, and although business value should be the main driver other aspects also influence decisions made by a Product Owner. It’s worth remembering that there is a difference between value and priority.
OK, but how does a Product Owner know a business value of all the stories? Of course, it’s a Product Owner’s job to understand what set of features the product needs to have to delight its users, but how does a Product Owner make day-to-day decisions when a product backlog consist of hundreds or thousands of items? Relative Value Points (see Agile Project Management by Jim Highsmith) and ROI is the answer.
Value points are somehow similar to story points, but they are calculated top-down instead of bottom-up. The idea is that value points (i.e. 1, 2, 3, 5, 8 and 13) are assigned to features first, and then a percentage of total feature points is calculated for each feature (i.e. three features with 3, 5 and 8 value points assigned get 19%, 31%, and 50% respectively). Next value points are allocated to stories (the same way), but the percentages assigned to a set of stories are capped by the percentage of their parent feature (i.e. if the first feature consists of two stories with 2 and 8 value points assigned, the percentage for these stories is 4% and 15% respectively).
As a result of using this simple algorithm all the stories in a product backlog have a percentage value assigned. A value of each story is relative to other stories and, therefore, allows for comparing them with regards to a business value they deliver to clients. Relative value points can be further used to allocate revenue stream or net present value (NPV) to features/stories, but most organisations don’t go through this step (many organisations don’t do a good cost-benefit analysis at all).
Value points have another advantage – they increase transparency and understanding in the team. They can be also used to calculate a relative ROI (Return On Investment) for each story which is another tool that can help the team make better decisions regarding priority of backlog items. In this scenario, relative ROI can be defined as a ratio between the business value of a story (in value points) and its complexity (in story points). Please bear in mind that relative ROI can’t be converted to money, but allows for comparing user stories – a chart below can help Product Owner see which stories have best ROI:
