Prioritization Made Simple
Lessons
Use MoSCoW to take a first quick pass at prioritizing your Backlog
Be strict and draw a distinct line between your Must-haves and Should-haves
Make conscious trade off decisions and let everyone know what you Won’t-have
I am generally a fan with starting simple, using the iterative modus operandi of Agile, and prioritization is no exception to this rule of thumb. At this point you have a backlog - a list of anything your team might ever do - but it’s not prioritized yet. Your end goal in a perfect world is to calculate an accurate ROI for each work item, incorporating projected revenue from the added feature, the cost to build it, etc. and let this drive your prioritization. But this can be quite time intensive especially for small organizations or those who aren’t practiced in this kind of estimation. Though this should remain your end goal, are there any steps between these two conditions of being - completely unprioritized and perfectly and objectively prioritized? The answer is yes.
If completely unprioritized is Step 0, the MoSCoW (read: Moscow) method is step 0.5. Credit goes to Dai Clegg, who developed it in 1994 for use in Rapid Application Development (RAD). What I’ll outline is too subjective to serve as a final state, but if the backlog is brand new and your team needs to get started on something now, or if you just need to get your prioritization to ~50%, it can serve as a valuable and very fast framework to guide you. The acronym stands for Must-have, Should-have, Could-have, and Won’t-have. We’ll be talking about this in the context of an entire product backlog, but you can scale it down to the context of a single Sprint or even a single User Story and its tasks if you feel so inclined.
Must-have
This is often the easiest place to start, as these are the things that absolutely must be built, however it can be incredibly tempting to incorporate too much stuff in this category. It’s easy to think to yourself, “Well this is incredibly valuable, we should certainly have this in the first iteration". And you might have it in the first iteration, but there is a distinct difference between Must-have and Should-have, as we’ll see in a bit, and if you have to cut something from the first iteration in order to get it to your customer sooner, your Should-haves will get cut before your Must-haves.
Let’s take a car for example, or by its simplest definition - a vehicle by which you can move from Point-A to Point-B more efficiently than walking. By this definition, the wheels are Must-haves, the Engine is not. In fact, neither are the tires. Actually taking it a step further, what is a Must-have is a wheel in it’s most generic definition, not a metal disk built to accommodate a tire.
Another Must-have is a platform that can support the weight of a single person. A third would be a way to connect the platform to the wheel(s) in a way that enables them to keep turning. That’s pretty much it. If you have a platform with a wheel(s) attached, it can support you, and the wheels can rotate, you have yourself a vehicle that can transport you from Point-A to Point-B more efficiently than walking.
Now there will also be prioritization within must-haves as well, in fact within all the categories. For example, the platform is probably the highest priority. There are a number of situations in which a platform (snow, water, down hills, etc) can transport you more efficiently than walking. High relative return, low relative investment. Next would be the connecting mechanism for the wheels, as building the wheels separately would likely be more effort/investment, and completely useless without the connection, but the connection is relatively low investment in comparison though also useless. Same return with less investment = higher priority. Starting to make sense?
Must-haves are the most important category to define, and thus the most important to be strict about. Be intentional about drawing a distinct line between them and Should-haves.
Should-have
Once you have your strictly defined your Must-haves, and drawn your line, Should-haves will be pretty easily to populate or begin to organize. These are the things you were already thinking about including in your Must-haves, but decided not to. They, like Must-haves should be prioritized within the category based on subjective and estimated ROI, started with relatively high-return-low-investment and ending with relatively low-return-high-investment within the context of the category. Within the context of the entire backlog, Should-haves should still all be relatively high-return-low-investment. The hardest part again, however, is drawing a line between the Should-haves and your next category, Could-haves.
This is arguably the hardest line to draw during this whole exercise, because as you work your way beyond the obviously high-return-low-investment items the clarity of the ROI, because it’s a subjective estimate, becomes incredibly blurry. However this line is also less important to draw than the one between Must-haves and Should-haves. It’s less important because the further down in the backlog you get the more likely it is that you’ll have learned more and shifted your direction. For this reason, also making a distinction between your last Could-have and your first Won’t-have is a frivolous pursuit. My advice is to do your best to draw a line between your Should-haves and Could-haves, but don’t obsess over it. The important part is that you have your highest-priority Should-haves identified and prioritized, as these will be the items that your team will be looking forward at and planning for in anticipation of the next product iteration.
Could-have & Won’t have
Could-haves are your least important items that you still hope to do at some point. This is the biggest distinction between them and Won’t-haves. Won’t-haves are the specific things you’ve decided you won’t do. They are your tradeoffs. They are not necessarily completely void of value. In fact, they might even be fairly high return, but they’re likely so high in investment that it doesn’t make it worth pursuing, at least not when compared to everything else you could do. Because of this distinction, Could-haves will be on your backlog, and Won’t-haves won’t even be written. It is intended to serve as a valuable mental exercise where you specifically and deliberately decide what you’re sacrificing.
Conclusion
The MoSCoW method is a quick, efficient, first-step in prioritizing your backlog. Though it’s simple, it can be difficult to make some of the deliberate decisions involved. Most importantly, identify your Must-haves and be strict about it. Draw a clear line between those and your Should-haves, and put them at the top of your backlog. Should-haves come next in subjectively estimated ROI order, followed by your Could-haves. Make clear decisions about your Won’t-haves. It might be hard, but it’s important for everyone to know specifically what you will not be doing. Don’t document them on your backlog, but make sure everyone is aware.