MoSCoW prioritisation is a method for collating all your features, user stories and feature requests into an sense of order, identifying what is most important and therefore should be delivered first or given the most concentration, within software development projects.

My particular umbrage with MoSCoW is the “Won’t have”. In my opinion this is wrong, it’s negative, it dismisses features or requirements because there isn’t enough time to complete them all. A perfectly valid viewpoint I hear you say – but in my experience dismissing any feature or requirement at the stage of a project wherein you would use MoSCoW is far too early to begin dismissing anything.

MoSCoW offer fours levels of prioritisation:

M – Must have
These requirements are critical to the project. Without these in place we are not delivering what is required, even at the most minimal feature set.

S – Should have
These are important requirements, but they’re not critical, certainly not in the first phase of delivery.

C – Could have
It would be really nice to include these requirements and features and if we had extra time, or available team members then great.

W – Won’t have
These features won’t add much to the project. They’ve been dropped in favour of those that appear in the three categories above.

At the stage where you would use MoSCoW to help sort the wood from the trees your project probably looks something like this:

You won’t have written any code yet (maybe just a proof of concept), there might (should) be a specification of some sort and you’ll have a list of features and requirements that need to be there.

Once you’ve gone round the run of prioritising the work, you’ll might end up with this.

Now, if that last column had been “Won’t have” then you’ve ditched “Feature D”. If there are stakeholders in the room with you, then you’ve all decided that “Feature D” didn’t make the cut. “Feature D” might be really cool, but up against what else is required at the beginning of the project it wasn’t cool enough to override the other three requirements.

Let’s say that half way through the project your budget increases, more people join the team, and the project is ahead of schedule. You finish the “Must have” features easily. “Should have” and “Could have”, all wrapped up. But what about that really cool feature everyone dismissed at the beginning. Chances are it’s long gone, in fact, as a team, you’ve never referred to the “Won’t Have” column since the initial meeting, why would you. It’s dead. The feature won’t happen.

Some argue that the use of the “Won’t have” column is for features that are outside the intial scope. My response is that if they’re outside the scope of the project from the outset, why are they being prioritised? Anything out of scope should have been dismissed before they were even discussed for prioritisation.

In my years of using MoSCoW I’ve always changed the last column, from a “Won’t have” to a “Would have”, turning a negative into a positive and keeping the door open to those great ideas and features.

W – Would have
We would add these features in if we had more time or team members available on the project.

By keeping the last column as “Would have” you retain a window of opportunity, you keep an optimistic view instead of a negative one. You’ll keep a collection of features where, should the best happen and more time be available, you can make your software project even better.