The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

The Steep Curve of Feature Prioritization

How to prioritize features for development? Which to do first, which then, which last? That’s a much debated aspect of software development. And most teams I know are not very systematic about it.

That’s a pity, because doing features in the “wrong” order means creating value for the customer slower than possible. Or it even means producing waste.

In his recent book “The Nature of Software Development” Ron Jeffries showed how he thinks prioritization should be done with nice drawings like this:


Each rectangle represents a feature with a certain value to be produced with a certain effort (time, money).


The higher the “feature box”, the more value is produced. The longer the box, the more it costs to produce the value.

As Ron Jeffries’ drawing clearly shows, there are several ways how to order (prioritize) features. In the end, the same value is produced over the same time. But how fast how much value is added may differ greatly.

Prioritize by Value

His suggestion is: Implement high value features first, postpone low value features as long as possible. This makes for a steeper value growth curve. In the above drawing the top order of features is to be preferred. It grows value faster than the bottom order.

I agree.

But is it really that easy? Just order features according to value and effort? Take this assortment of features for example:


Features s..x are of the same value - but require increasing effort. Features d..a are of decreasing value - but require the same effort. The order in which to build thus is in decreasing value and growing effort.


I think, this is what Ron Jeffries had in mind:

Look at the difference in the growth of value if we choose the higher value inexpensive features first and defer lower value costly features until later.

But, alas, features usually don’t come in such nicely cut variations. The range of values and efforts is larger. Take the following features for example:


Building them in this order leads to this feature value growth curve:


Still not bad, isn’t it. A concave curve showing how value is produced quickly right from the start.

Prioritize by Weight

However… We can do better. And that’s what’s missing from Ron Jeffries’ book. Ordering features by value and effort easily leads to suboptimal curvature.

Let me show you what I mean. Here’s an alternative ordering for the same features:


Value growth looks steeper, doesn’t it?

How is this? What’s the criteria for ordering the features? It’s obviously not just value, because for example feature c is done before x which provides higher value.

The criteria is called weight. It’s calculated as described by the Weighted Shortest Job First (WSJF) method. It takes into account not only value, but also effort.

weight = value / effort

The higher the weight, the higher the feature should be prioritized.

In a diagram weight can be found in the angle of the diagonal of a feature box. Or to be precise: Since we don’t know the angle, it is the tangent of the angle.


The larger the angle, the steeper the diagonal points upwards, the higher the weight, the earlier the feature should be implemented.

What this means for prioritizing the above features shows the following figure where the features are ordered according to their weight:


You see: the angle progressively becomes smaller, the inclination of the diagonals decreases. And that means, the value growth curve is steeper, when you implement the features in this order.

Compare the value-focused prioritization drawn with triangles


to the WSJF prioritization:


The growth of value is steeper and smoother with the WSJF prioritization, there are no slumps in the curve.

Of course, value-focused prioritization and WSJF prioritization result in the same order for features of same effort. So the question is: Can you slice down requirements to be of the same effort - and still “calculate” a meaningful value for each of them?

I’d say, that’s possible - but only pretty late in the game. You already have to be very clear about a lump of requirements to break it down into (roughly) equally sized increments.

That means, mostly you’ll need to prioritize the hard way and do it in WSJF manner.

Finding Value

However, regardless how you prioritize, you need to find the value of your features. How to do that?

In my experience it’s rarely possible to find a monetary value. For large features (whole applications or modules) this might work, but not for smaller features. How many more customers will buy your software if you fix this bug or add the PDF export? How many customers will cancel the subscription to your online service, if you don’t fix the bug or improve usability?

“Cost of delay”, i.e. how much money you’ll loose/not earn as long as a feature is missing, is very hard to determine. I can’t think of any client of mine who would know (on a regular basis).

So what’s the alternative? Choose whatever fits the bill. If you’ve several thousand users you can speculate about how many of them will benefit from a feature. Or even with a few users you can ask yourself, how often they would use that feature on average (each day or each year). Or you can think about how crucial a feature is for their business. Or you can check for dependencies between features; a feature other features depend on might be worth more, because its kind of enabling. Or maybe lacking a feature poses a tangible risk, because the software would loose an important certification.

Find any number of criteria applicable to your software. And assign values to them. You can go with scales from 1 to 5 or the Fibonacci numbers. It’s less about precision as it is about comparability.

Maybe you find just three criteria. That’s better than just a gut feeling. If you range each from 0 to 5 the minimum value for a feature is 0 and the maximum value is 15.

Even with these few criteria talking about feature value becomes more differentiated and objective. Less guessing, more thinking.

Determining Effort

The same is true for determining the effort needed for a feature. We’re talking about estimation here. A sensitive topic for software developers and managers alike.

Calculating the time needed to do a feature with high reliability is near impossible. Ron Jeffries makes that very clear in his book and I can only agree.

So we should not try to predict absolute effort. Fortunately for prioritization it’s sufficient to just determine efforts for comparison. This feature will take x amount of time, that feature will take two times x, and another will take just half x.

Again a simple scale will do. Or go with the Fibonacci numbers again. Yes, it’s almost like with Story Points in Scrum. But don’t fall into the prediction trap! Don’t try to forecast how many features you’ll be able to deliver in a certain amount of time.

As soon as you start forecasting there will be people who take this for (future) reality and depend on the forecast to become true. That reduces your flexibility, that creates pressure. So by all means: Don’t forecast! Take effort figures as abstract numbers just for comparison. Assigning a 2 today will not mean the same when assigned to another feature next week.

Try to do it like this: When determining the effort for a number of features start by finding the smallest one. Assign to it 1 as the effort. Then determine the relative factors for the other ones, e.g. another feature takes twice as long (effort becomes 2), yet another feature takes much, much longer (effort becomes 10) etc.

As should be obvious: The smallest feature in today’s prioritization round can be much smaller or much larger than the smallest feature in the next round. So a 1 cannot be converted to a certain number of hours or days.

Instead of promising a result (“We will deliver features a, b, c in one week’s time.”), you should just promise a behavior (“We will deliver features a, b, c in order of their priority - which might even change over time.”).

Remember: It’s always good to promise like a pro! ;-)

Bottom line: When building software go for incremental value delivery. But value alone is not enough to prioritize. You need to take effort into account. You achieve the steepest growth in value when you prioritize based on feature weight, which essentially means you calculate a speed: “value delivery speed” equals feature value by implementation time. Bet on race horse features first, leave the nags for last.

Print | posted on Sunday, November 30, 2014 2:21 PM |


No comments posted yet.
Post A Comment

Powered by: