Priority vs Business Value

Question

We use a sort of cruddy old SLDC module in Service Now for keeping track of sprints. It has a field for Story Points and Priority. Priority is 1 - Critical through 5 - Moderate. Does this track with Business Value in the Scrum World?

At my previous job, where I was scrummaster and we used paper to track stories (at least during the sprint), I asked the Product Owner to place a number (in the same scale as story points, but I don't think that's essential) on each of the stories he brought with him to sprint planning. Then we did our ROI calculations to prioritize our work.

Now, I don't see this "Priority" in Service Now being anything but a holdover from people who don't understand or care about Scrum.

What is the difference between priority and business value and how can I effectively communicate that we, as a scrum team, need a Product Owner who puts business value on stories?

Answer 1

TL;DR

The Product Owner can track business value or other information on items in the Product Backlog. However, from a process perspective, only the sequential order of Product Backlog Items really matters. The sequence can be negotiated with the Product Owner, but that person is the sole and final arbiter of Product Backlog contents, including its ordering.

Useful Definitions

I won't bother with dictionary definitions here. Instead, I'll discuss pragmatic definitions in terms of successful Scrum implementations.

"Priority" is ordinal. It provides the Scrum Team with a sequence of items to work on in descending order.

"Value" is a subjective measure of how useful stakeholders think some feature will be. This is often financial (e.g. "How much money will this feature make our company?") or utilitarian ("How useful will this feature be to our target user?").

A Product Backlog Must Be Sequentially Ordered

In Scrum, the Product Backlog is strictly ordered by the PO-defined priority of the items it contains. This priority is solely defined by the Product Owner, although often with input from stakeholders and other members of the Scrum Team. An ordered Product Backlog sets out the sequence of items to be worked on, but that order can (and frequently does) change between Sprints or through negotiation with the Product Owner.

While value may impact the order set by the Product Owner, such as by placing higher-value items closer to the top of the Product Backlog, the "value" (if any) is never tracked on the Sprint Backlog because it's largely irrelevant (from a process perspective) to the Development Team. Discussions about value are usually between the Product Owner and stakeholders, and sometimes between the Product Owner and the Development Team during Backlog Refinement or Sprint Planning, but managing or assigning the business value of features (as opposed to incorporating the value statement of the viewpoint character from a well-written user story into planning and development activities) is not a defined responsibility for the Development Team.

The Product Owner is solely responsible for the content of the Product Backlog, and so they can certainly note business value or any other details they like on Product Backlog items if it helps them do their job. However, from a whole-team perspective, only the sequential order of items on the Product Backlog matters.

Answer 2

It all depends on how you define business value and priority. It would be easier if you forget about the labels and focus on the final goal: the final goal is to create a product that doesn’t have all the possible features, and yet has the highest benefit/development_cost ratio among the products with different combinations of features that are created with the same capacity and limitations. The features that are needed to bring you toward that product will go to the top of the product backlog and will be ordered based on their contribution to the final benefit/development_cost ratio.

In an oversimplified model, we can think of benefit/development_cost ratio of single items and use that to order the backlog. This is not completely realistic, because the benefit of each feature has a nonlinear relationship with other features that you have in the product. If you believe that this nonlinearity is significant, you will have to use a holistic perspective to order the items, and otherwise, you can use the simplified method.

The benefit/development_cost ratio is what serious resources on value management (e.g., MoV from AXELOS) call value, which may be confusing, because the day-to-day meaning of value is the same as benefit (e.g., when people say “it’s good value for money”).

When the nonlinear relationship among items is significant and you’re still forcing yourself to use value for ordering, you will find the need to consider extra criteria to improve the ordering. These extra criteria are those that usually summarized and labeled as priorities, and then combined with business value to order items. It can be a quick fix to the problem, but most priorities have double-counting problems and can’t help as much as they should. However, there are certain types of prioritization that can work on a higher level and even contain the business value; e.g., MoSCoW prioritization (with its precise definition in DSDM). You can use MoSCoW to categorize features into 4 relatively objective groups, and then use a rough estimation of business value to order the features inside each group.

Answer 3

Business value is a factor in priority, but there are other factors to consider as well.

For example, a medium value item might end up getting prioritised over a high value item because it is quicker and cheaper to do.

Technical factors may be involved as well. The team may advise the Product Owner to change the priorities due to some technical reason.

Also, there is a people element to prioritisation: perhaps the team wants to delay starting a particular item until somebody returns from sick leave.

The conclusion is that priority and value are best stored discretely. A common approach is to note the value as a field on each item and then use the order of the items as an indication of priority.

Answer 4

In the Product Backlog, the order of the items matter. The ones at the top have higher priority so make sure you get this right. There's no need to fill the Priority field, just move the item higher.

In the Sprint Backlog, the priority field of the User Stories can be used to show which user stories are more important (to the Product Owner) than others.

For example:

Five user stories are selected in the Sprint Backlog:

• 1 critical
• 2 high
• 1 moderate
• 1 low

It is clear for the Development Team what is should deliver first.

The low priority user story (and even the moderate priority user story) might not be delivered by the end of the Sprint, because the priority is to deliver the critical and high ones.