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.

Post to Twitter Post to Facebook

This article was published on Wednesday, January 18th, 2006 at 11:01 pm and is filed under Lists, Prioritization, Project Management, Requirements, Software requirements specification.
You can leave a comment on this post


  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. 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 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. :)

13 Trackbacks

  1. [...] One ROI benefit of good requirements is being able to work on the most important stuff first. The top 3 reasons for project failures identified in their poll: [...]

  2. [...] Organizing, validating, and prioritizing these capabilities is the hard part.  The output of this effort is a PRD.  A product roadmap (a vision of what a product will be capable of doing, over time) is another potential output. [...]

  3. By Top five ways to be a better listener -Tyner Blain on January 29, 2006 at 10:59 pm

    [...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]

  4. [...] 2. How big of a problem is our quality? When reporting quality status to a non-technical manager, we are often asked “OK, there are 100 bugs – how bad are they?” The same issues that we struggle with when prioritizing requirements are also at the root of problems in prioritizing bug fixing. [...]

  5. By Definition of expected value -Tyner Blain on February 3, 2006 at 8:55 pm

    [...] Understanding the expected value of a possible future event allows us to make mathematically sound decisions.  We can decide if we want to make an investment.  We can assign a reasonable price for our services.  We can prioritize requirements.  Expected value is a calculation that should be used when calculating ROI. How is expected value calculated? Have you ever participated in a 50-50 raffle? This is a common fund-raising technique in the US for school groups, organizations, etc. The group sells raffle tickets (each ticket has a uniquely identifiable number, and there are two copies of each ticket) for $1 each to people. Each person gets one half of the raffle ticket, and the other half gets put into a drawing. After all of the tickets have been sold, the organization randomly picks a single ticket. The person who has the matching number on their raffle ticket wins half of the money collected by the group. The group keeps the other half. [...]

  6. By pauliehaha on February 15, 2010 at 8:41 pm

    Requirements should be prioritised based on ROI and value to the user, not on making one person's life a little easier.

  7. By Sunday Blogmarks « Managing Software Development on January 15, 2011 at 4:55 am
  8. [...] Three alternative techniques [...]

  9. By Adrian Reed on September 10, 2012 at 9:41 am

    Just found this article by @sehlhorst "Prioritizing requirements – three techniques". Love the McDonalds analogy! #baot

  10. By Will Hughes on September 10, 2012 at 5:11 pm

    Just found this article by @sehlhorst "Prioritizing requirements – three techniques". Love the McDonalds analogy! #baot

  11. By Craig Gus Jeffries on September 10, 2012 at 6:14 pm

    Just found this article by @sehlhorst "Prioritizing requirements – three techniques". Love the McDonalds analogy! #baot

  12. By Craig Scott on September 14, 2012 at 6:50 pm

    Just found this article by @sehlhorst "Prioritizing requirements – three techniques". Love the McDonalds analogy! #baot

  13. […] Prioritizing requirements – three techniques by Tyner Blain. Tyner describes three techniques: classical, exhaustive and value-based. He states: “The […]

Post a Comment

Your email is never published nor shared. 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>