Prioritizing requirements – three techniques

Now that we’ve gathered all these requirements, how do we determine which ones to do first?

The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.

1. Classical. Let stakeholders assign priority to the requirements.
2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
4. [bonus]. A look at how 37signals prioritizes features for their products.

1. Classical

We’ve all been in a discussion at one point where we ask people to prioritize a set of work. The classic example is during triage of outstanding bugs – high priority gets overused so much that people start inventing very high priority and ultra high priority.

It’s like when McDonalds got rid of the small size french fry – now they have medium, large, and super size fries. What happened to small? Wendy’s is even worse – large, biggie, and great biggie sizes. They even lost the medium size.

We can try to avoid this problem and force an even distribution of high, medium and low requirements. A simple approach, and we used it when we are facilitating a brainstorming session. This works great when we’re working in the abstract, or prioritizing brand new ideas as a starting point for future discussions. However, when truly prioritizing requirements, we run into people who think everything is critically important. Try to force these people into three equally sized buckets and they will revolt. Without careful prompting, I’ve never seen a session result in fewer than half of the “real” features (or bugs) in the high priority bucket.
We can learn something from the french fries here. While marketing may put names like “value sized” and “eat this and it’s free” on the different sizes, the bottom line is that there is one size which is the smallest, one size which is the largest, and one size which is in the middle. It’s all relative. The same is true with requirements, so…

Subdivide the high priority requirements.

More than half of our requirements are high priority, with the remainder in medium or low priorities. Ask the folks to break down the high priority pile into two or three piles (like biggie and great biggie fries). They still won’t split things evenly, but now the largest group of requirements is roughly a third of the total set of requirements (and represents the highest priority requirements). These are the new high priority. With the remaining three or four piles of prioritized requirements – combine the groups to create medium priority and low priority requirements.

We now have workable classifications of priority for our requirements.

The problem with this approach is that we don’t know how much more important the more important requirements truly are.

2. Exhaustive.

Here is a very extensive article about prioritization written by Donald Firesmith of the Software Engineering Institute. Early in the article, Don gives us three possible interpretations of the definition of prioritization. He talks about why we prioritize, the risks of not doing it right, and explains no fewer than 14 different axes along which we might prioritize. He references several good resources, details a process (and a sub-process), and tells us more than we would ever want to know about prioritization.

My suggestion – skim the article, read about the different axes (section 5) if you plan on using the classical technique above, and bookmark the reference for the future. This is pretty dry reading – and I even enjoy reading technical specs for telecomm switches. However, I do recognize the breadth and validity of the content he has pulled together.

Unfortunately, what Donald doesn’t do for us is prioritize his content. The organization is logical, but some of it is clearly fluff, and some of it is valuable, and we can’t tease those sections apart.

3. Value-based.

Our customers buy our software because it increases their profits. It’s an investment for them. The payback can be in cost-savings (bottom-line growth) or increased sales (top-line growth), or anywhere in between. We could be cutting overhead (and therefore cost of goods sold) by reducing their cost-to-quote. We could be optimizing their supply chain (reducing the dollars invested in work-in-process inventory), or we could be opening up a new sales channel (a portal website for resellers to directly submit orders to the factory). The bottom line is that it all comes down to ROI.
In a comment on a recent thread, Marcus asked how we would trace requirements to corporate strategy. One example he used is the tactic of becoming the low-cost provider in a market. We have to abstract that back up to get to the dollars. Follow the money. A low-cost provider can increase market share, and potentially lower costs through automation. The strategy was presumably accepted (by the business) based upon a projected impact on company profits. We need to understand that impact-projection, and use the resultant profitability forecast to value our requirements.

This is a good example of why document analysis is important to eliciting requirements.

Prioritize requirements based upon their explicit impact on profitability. With requirements traceability, we can break down the impact of supporting requirements as a percentage of the impact of those requirements that they support. This represents implicit value for a particular requirement. This is one of the benefits of using a structured requirements framework. Also, when using composition in requirements, we will distribute the impact assessment to the sub-requirements.

If at all possible, implement the most valuable requirements first.

In the real world, there are two constraints that we have to live in when taking this approach. First, there are implementation dependencies. There are some parts of a work breakdown structure that must be done before others (due to entanglement in the design, or availability of resources, for example). When incorporating this reality into the schedule, still prioritize more value ahead of less value.

The second real-world consideration is the executive whim – there are often personal agendas, political pressures, and perceptions held by the stakeholders that will create pressure to implement some features with low intrinsic value ahead of some features with higher value. While people may optimize by nature, it isn’t always the company’s bottom line for which they are optimizing. Try and work with these people to prioritize the high value features first. Be compelling. It may be that there are tactical considerations (the CEO may demand that the website match corporate look and feel standards before it allows for new order submission), and the funding for the project may be dependent upon addressing someone’s pet peeve in the first release. We just have to do it some times.

Prioritize based upon the value that a set of features will bring to the business.

When we’re writing the specs for multi-customer software, the business who’s value we prioritize is ours. This abstraction can be harder to address. But a given capability will be expected to have an impact on our ability to sell the software (or raise the price of the software). And it will come with an inherent cost. Leverage strategic marketing expertise to pick the right capabilities (more importantly – solve the right problems), and properly value them.

By changing the customer from them to us, we can apply the same principals for value-based prioritization.

4. Bonus. We talk in another post about how 37signals approaches software requirements prioritization.