The ABCs of Software Requirements Prioritization

One of the best and simplest approaches I have used to help teams get clarity and focus around feature prioritization has been to categorize each feature by an A/B/C prioritization. Using this approach can help provide the balance necessary to allow tradeoffs of scope and schedule while accounting for the inherent uncertainty that is present in software projects. We categorize all the desired features into three priority levels:

A MUST be completed in order to ship the product and the schedule will be slipped if necessary to make this commitment.
B Are WISHED to be completed in order to ship the product, but may be dropped without consequence.
C Are NOT TARGETED to be completed prior to shipping, but might make it if time allows.

The key is that only “A” features are committed, although we expect many of the “B” features will also be delivered. In order to manage the uncertainty we recommend that only 50% of the schedule is filled with “A” features. If more than 50% of the schedule is allocated to “A” features it is a strong indicator that the project delivery target may be at risk.

When teams follow the general guidance, they are positioned to be able to adjust to both the uncertainty associated with the original estimates as well as the uncertainty associated with the project scope. The following example shows a common scenario where the overall estimates were close to the actual, but where discovery of the scope resulted in a movement of some “C” features to be prioritized higher than some of the “B”s, and where there were new “D” features that were viewed as important but had not even considered when the original plan was established.

Priority Target Allocation Typical Result
A 50% 50%
B 50% 25%
C Not in target 12.5%
D Not known at time of target 12.5%

However, what happens when the original estimates were significantly underestimated. The selection of 50% as the maximum allocation for commitments is not arbitrary. Multiple studies of software project estimation have shown a 2X range of uncertainty to be the norm.

Priority Target Allocation Worst Case Result
A 50% 100%
B 50% 0%
C Not in target 0%
D Not known at time of target 0%

This simple approach has worked well to establish expectations and allow teams to meet those expectations. With regard to expectations, it is important to manage the expectations of the “A” features. Since these were promised to stakeholders it is critical that prior to dropping any of these features expectations must be reset with the stakeholders.

This approach is quite similar to the MoSCoW model, but I prefer the ABC model for a couple of key reasons. First, I think it is simpler. I joked once at a DSDM conference (where MoSCoW is very prevalent) that the ABC approach was “MoSCoW for preschoolers.” But I think it is even more powerful due to the specific action consequences that are spelled out by the ABC approach. MoSCoW just states that the Must Haves are necessary for project success, whereas with this ABC model we explicitly call out that the feature is so critical that the release will be delayed in order to complete the feature. I also find that the use of “Should” is loaded.  It gives the connotation that if they are not delivered the team fell short.  I far prefer “Wishes” as I see that category as more like a Christmas Wish list–we’ll likely get some of them, but probably won’t get all of them.

About Todd

Todd Little is VP of Product Development for IHS, the leading provider of information and analytics shaping today’s business landscape: energy, economics, geopolitical risk, sustainability and supply chain management. For over 30 years he has been involved in almost all aspects of software development with a focus on commercial software applications for oil and gas exploration and production. He is on the Board of Directors for the Agile Alliance. In 2003, he co-founded the Agile Development Conference, and served as the General Chair for ADC2004, Agile2005 and Agile2006. He has returned for the 10 year anniversary of the Agile Manifesto to be the General Chair of Agile2011. He is a co-author of the Declaration of Interdependence for Agile Project Leadership ( and a founding member and past President of the Agile Project Leadership Network (APLN). Along with Pollyanna Pixton, Niel Nickolaisen, and Kent McDonald, he is a co-author of the book “Stand Back and Deliver: Accelerating Business Agility,” Addison Wesley
This entry was posted in Uncategorized. Bookmark the permalink.

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>