Prioritizing requirements – three techniques

A zillion identical ice cream bars

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.

French fries

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.

18 thoughts on “Prioritizing requirements – three techniques

  1. Great post! ROI with dependencies is the best prioritization methodology, IMHO. Development is really an investment and one would not invest where the expected return is low or minimal (under normal circumstances.)

    I am thinking there may be a 3rd reason why a high ROI requirement is implemented after another one – legislation & compliance. For example, dates for the implementation of controls for SOX or privacy policies may be beyond the control of a steering committee. I am not sure if these types of requirements would be adequately covered off in non-functional requirement documentation.

  2. Prioritising projects in a marketing department yields the same results. I suggested the review board rank them and better results were yielded.

    I wonder if this would work for requirements. At the least it should get the most important features built first.

    By ranking you have to put some ahead of others, and you probably have a set of mandatory requirements you can’t release with, but it helps in the middle of the pack when resources and time start to become scarce.

    Usually I like to use the Kano model but it might be interesting to try.

  3. Hey Craig –

    I like the Kano model, at a minimum, for classifying what the requirements are. It provides a sanity check – are the “must haves” really the “must haves?” And then utility / value drive the next set of requirements to be scheduled.

    In my experience, satisfying the buyer persona tends to overwhelm the user persona’s needs for early releases of enterprise software. For B2C, the buyer is usually also the user – but wearing a different hat. In other words, when making a purchasing decision, the user will evaluate the software differently – a checklist of “can I do X” is what they will use. Or they will get feedback from others – “how easy was it to do X?”

    Tough balancing act.

  4. Pingback: pauliehaha
  5. Pingback: Adrian Reed
  6. Pingback: Will Hughes
  7. Pingback: Craig Gus Jeffries
  8. Pingback: Craig Scott
  9. Hi Scott,

    Thank you for posting this article. I noticed it while looking for ideas.

    What if its hard to talk about ROI, such as when creating a product for government agencies, say, homeland security. While there is of course a cost factor involved the result is not really measurable in classical business ROI terms …

    It looks like one would need to analyze client concerns such as contribution of requirements to efficiency of work, safety etc.

    thanks,

    Daniel

    1. Thanks for the great question, Daniel!

      Ultimately, you are prioritizing based on the relative impact of the requirements to the goals you’re trying to achieve. The _return_ in ROI doesn’t have to be dollars, as you mention. It could be measured in terms like “percentage reduction in security threat” (which would allow you to rank improved airport security investments vs. improved highway security investments) or “reduction in RSI injury claims” or “output per person per hour.”

      These measures are more tractable, and while they ultimately lead to $, if the goals for the project are already fixed (e.g. improve X by Y amount), then use the “Y amount” proportions for your relative value comparisons.

      Does that make sense? I’m making assumptions _and_ trying to be general at the same time. I may have ended up just being vague. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>