Back in Chapter 3, Introducing Scrum to Your Software Team, we looked at product backlog definition and release planning and introduced a prioritization technique called Must have, Should have, Could have, Won't have (MoSCoW) as a quick way of prioritizing our backlog.

This technique, just like the buy a feature technique, aims to place value on features, often based on the Product Owner's gut instinct.

There are alternative ways of prioritizing features and User Stories that put an explicit emphasis on value. 

Value comes in several forms, direct revenue, the most obvious, being just one of them. Comparing features that increase direct revenue with features that reduce costs, or enhance our product's brand, can be like comparing apples and oranges.

This disparity often makes it hard to objectively decide which features should gain priority on a product roadmap and which we could put on the back burner for now. We often favor the ones that increase our direct revenue because they're easier to quantify.

Cost of Delay (CoD) is one way of determining if whether we should do something now or later. Don Reinertsen, in his book The Principles of Product Development Flow, says it's one of the key measurements we should make use of when building a product.

In the simplest terms, we can think of it in terms of a $/week value for every week we delay releasing a new feature. 

For instance, if we have two features that we'd like to develop:

• Feature A would generate us $1,000/week in additional revenue.
• Feature B would reduce costs by $750/week.

In other words, for every week we delay releasing Feature A, we miss out on extra $1,000 revenue, and for every week we don't release feature B, we spend $750 more than we have to. Assuming the time taken to develop both is the same, then Feature A, with its higher cost of delay, would be the obvious choice.

However, not all features are the same, and it's unlikely that both features will take exactly the same amount of time. In fact, imagine that Feature A takes 16 weeks, while Feature B will take 4 weeks.

Feature A: $1,000/week will take 16 weeks to build

Feature B: $750/week will take 4 weeks to build

Which feature should we build first? If we look at doing these sequentially with one team, there are two options—we build A then B or we build B then A. 

Build Feature A then B: B's cost of delay while implementing A is 16 weeks at $750, so $12,000.

The following diagram shows the cost if we build A then B:

Feature B then A: A's cost of delay while implementing B is 4 weeks at $1,000, so $4,000

The following diagram shows the cost if we build B then A:

We only have to wait for four extra weeks to get A after building B. If we built A first, we would have to wait 20 weeks for B. 

So even though A's cost of delay is higher per week than B's cost of delay, when we factor in the duration each takes to implement, it makes economic sense to build Feature B before we build Feature A.

The Scaled Agile Framework (SAFe) suggests we quantify three aspects of the value of a product feature when calculating the cost of delay:

1. User value or business value: How much value will this feature give to our customer or business?
2. Risk reduced or opportunity enabled: Will this feature reduce the risk to our business? Or will it enable a new opportunity?
3. Time Criticality: Is there a timing factor that is too important to ignore, for example, a change to existing legislation that needs to be implemented by a cutoff date?

There are several ways we can quantify these variables. The simplest is to use a deck of planning poker cards, such as t-shirt sizes (XS, SM, M, L, XL) or the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, and so on).

We estimate in a group, likely product managers with technical representatives such as architects, tech leads, infrastructure and operation teams, and so on.

Once we've assigned the three values for UV|BV, RR|OE and Time Criticality using rounds of planning poker (see Chapter 3, Introducing Scrum to Your Software Team for the rules). We then add the three figures together to arrive at a single figure, which is our cost of delay:

 If we then factor duration into our calculation, it will help us manage our production pipeline more economically. So, as a final step, we also estimate the size of each feature, again using planning poker. If we then divide the CoD total by Duration (CD3), this gives us a single value which we can compare to others:

The feature with the highest CD3 is implemented first. So, using our example, the business value (BV) for feature A and B is $1,000 and $750:

The highest CD3 is Feature B, so we'd build that first. This comparison technique is also known as Weighted Shortest Job First (WSJF). We can use it to prioritize the feature that will return the highest value in the shortest time frame.