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.
