When you begin work on an initiative or something smaller like an individual feature or deliverable, it is important to know that not every piece of what you are about to start will have the same priority.
There will be items that are mandatory, items that are important, and items that are nice-to-have. Unless you can identify and classify which items are in which category, you run the risk of wasting time and effort on lower-priority items.
And, if you are in a complex environment where the needs of customers evolve quickly, you need a prioritization method that encourages fast feedback.
Here is a simple prioritization method that will help you identify the priority of the items within your work.
‘A’ Priority – Must Do
These items must be completed or there is no point in even starting this initiative. All of these items are required for delivery. These are the items that define the initiative.
If you are building a house, four walls and a roof are examples of ‘A’ priorities. If you are building a kitchen, a countertop to allow you to prepare food is an ‘A’ priority. Specifying that the countertop must be granite is a ‘B’ priority.
When all of your ‘A’ priorities are complete, your initiative or feature can be delivered and it will work. It will be functional. It may not be polished. It may not be pretty. But it will work. It will make that which wasn’t possible before, possible. Not necessarily easy, just possible.
If customer feedback is important to your work, share your ‘A’ items with your customers for feedback as you go. If possible, make your ‘A’ items available as ‘beta’ or ‘early access’ so that your more adventurous customers can start to get the benefit of your work, and so that you can get faster feedback on what to change or even what to build next.
‘B’ Priority – Need To Do
These items should be1 completed to ensure that you are creating something that is easy to use and meets your and your customer’s standards. Releasing just the ‘A’ items will result in the ability to do something new, but it might result in some customer dissatisfaction with the level of usability or polish.
‘B’ items get your initiative or feature to a place that you are proud to release it.
If ‘A’ items “make it work”, then ‘B’ items “make it work well.”
‘C’ Priority – Want To Do
These are the items you really want to complete to put all the polish into what you are delivering. This are the items that surprise and delight your customers.
And, these are the items that can be de-prioritized as needed.
Many times, these are the items that get you and your team excited. This is the new, fun and innovative stuff. And the danger is that you work on ‘C’ items before your ‘B’ items (or even some of your ‘A’ items) are complete.
How To Use
During the initial design/planning phases of your work, take all your ideas (they may be called ‘requirements’ at this point but they’re really just ideas) and group them into A/B/C categories.
Once you’ve grouped them, prioritize within each category and begin work with the highest priority ‘A’ item. Once that is complete, release it if possible and then begin on your second priority ‘A’ item, and so on.
Once you’ve completed all your ‘A’ items (and you have a functional deliverable), then begin work on the ‘B’ items. Do not begin any ‘B’ items until all your ‘A’ items are complete.
Only once the ‘B’ items are complete can you consider the ‘C’ items.
You will find that once you deliver a few ‘A’ items to your customers and get some feedback, the priority of your remaining items may change. Something you thought was an ‘A’ may turn out to be a ‘B’. Or something that was a ‘C’ becomes a ‘B’ or an ‘A’. This is to be expected. Re-prioritize based on the new information.
If you follow this prioritization process, you will find a few things happen.
Because you are focused on function first, the ‘A’ items you deliver begin to add value early. The feedback you receive on those ‘A’ items will inform the rest of your priorities.
If you deliver incrementally and iteratively and your customers use your solutions and provide feedback, you will find that items you originally thought were ‘A’ items become ‘B’ and that your ‘B’ items become ‘C’ items. You may find that you delivered 80% of the value with 20% of your planned work. When that happens, stop this initiative/feature and pivot to something else.
Some people (even on the team) will not be comfortable releasing the ‘A’ items without the ‘B’ items. They’ll argue that it isn’t done until all the ‘B’ items are complete. This might be true. Your initiative/feature may not be complete until you get all the ‘B’ items done, but that doesn’t mean you wait to begin delivering value until all the ‘B’ items are done.
Most of the time, what your customers want most is to see smaller, faster solutions. This prioritization method encourages quick value delivery with short feedback loops.
- By now you are seeing the parallels to the MoSCoW method. ABC Prioritization is an example of parallel evolution. It was not inspired by or informed by MoSCoW but evolved independently to meet a common need while working on initiatives and features. One difference between ABCs and MoSCoW is that ‘A’ priorities are what makes it possible to do something new. Possible is not the same as easy. ‘Must’ priorities in MoSCoW are often a combination of ‘A’ and ‘B’ items in this method. ↩︎