MoSCoW as a prioritization and planning tool

Posted on May 18th, 2007 in Agile by siddharta || 8 Comments

Prioritizing your backlog tasks is an important step. A core component of agile planning is that you deliver the most important features first. Important in this case, is whatever is valuable to the customer. It could be features with high business value, or features that are required to get a system into production, or perhaps features required to meet some regulation and so on. In order to be able to do this, you need a prioritized backlog. That way, the dev team can take the most important features and work on them first.

The most obvious way of prioritization is on a 1 to 5 scale, with 5 as most important and 1 as least important (sometimes the other way around). The problem with a numeric scale like this is that it is very difficult to decide on the number for a given feature. Is it a 3 or a 4? Maybe it’s a 5?

That’s where MoSCoW prioritization comes into the picture. In MoSCoW prioritization, instead of using numbers for indicating priority, we use labels: Must, Should, Could, Wont (hence the acronym MoSCoW)

Features that absolutely have to be done are categorized as Must. If any of these features are not done, the project will be considered a failure.

Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as Should.

Features that are nice to have but are not core features are categorized as Could.

Features that are not going to be implemented this time are marked as Wont. Why have these features in the backlog at all? There are two reasons. One is that feature priorities can change as the project goes on. These features could have started as Should and been re-prioritized to Wont, and they may be re-prioritized back again. The second is that these features are a starting point to the second version.

MoSCoW provides clear criteria for deciding on the priority of the feature, which makes it easy to quickly prioritize the backlog. It is also easy to make decisions when you want to re-prioritize the product backlog.

One anti-pattern that you want to look out for is in prioritizing the majority of the tasks as “Must”. If most of the features are prioritized the same, it is as good as not having a prioritization at all. Remember that features prioritized as “Must” should be only those features without which the project cannot be put into production, and will cause the project to fail. Usually this is a small set of important features. When you decide to mark a feature as “Must”, ask yourself if the project will have to be canceled if this feature is not implemented. Only if the answer is yes should you go ahead and prioritize it as Must.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

8 Responses to “MoSCoW as a prioritization and planning tool”

  1. JO Says:

    Something I find utterly disturbing with all these kinds of “prioritization schemes” is that they all fail a to me vital requirement: They do not put every item in relation to all other items.
    The hard, and so very very useful, with priorities is that every item gets its own and on two items get the same. If there are duplicates you haven’t prioritized, you have only grouped.

  2. Rob Says:

    Having worked in a company that used MoSCoW (although our “W” was for “wish” – i.e. less important than a “could” – I like “won’t” as a better alternative!) I can say that the adage that usually holds true is:

    When reading a requirements specification, mentally translate “should” (or “could”) into “probably won’t”.

    This is useful in two ways. Firstly, it indicates that really, on any project, the “musts” are the only features that are actually likely to get done (because schedules inevitably slip until eventually you ship some subset of the original plan, and that happens at the point all the mandatory features have been completed); secondly if you read “the spell checker should support UK and US English” as “the spell checker probably won’t support UK and US English” you then get a mental red flag waving if this feature should really be a “must”.

    Agree with JO that these kind of classifcations can make it hard to prioritize development of individual features: “text editor should include a spell checker; text editor should allow saving in Unicode and ASCII (8-bit) format” certainly gives you no clues as to which to work on first.

    MoSCoW does, however, make it easier to discuss feature importance to a customer or user in the early stages, as it’s instantly obvious which features they are likely to get without them having to compare priorities and/or know what the priority threshold is for implying “must have” features. Once you get into the development phase then the customer representative can start to assign priorities among the “musts”. The “shoulds” can be ignored unless and until there is spare development capacity once the “musts” have been addressed (planned or developed depending on your methodology)

  3. Brad Bellomo Says:

    A won’t list is also useful, since it avoids debating the same feature request twice.

    I agree with Rob, it is very important to distinguish between won’t as in CANNOT – such as the system won’t corrupt a datafile if it loses an internet connection, and won’t as in WE DONT HAVE THE TIME – such as the system won’t do your taxes because that isn’t what we are marketing it to do.

  4. siddharta Says:

    Interesting comments. I actually think that the fact it groups features and does not do a complete ordering to be one of the big advantages.

    It’s really hard for us to think at such a fine grained level of detail. What we really want to know is what to work on in the large. So we know we really have to implement login and logout, but spell check can probably wait till later and the forum system can wait till next time.

    I’ve found that putting everything into an ordered list is very hard to do. Scrum actually asks you to do exactly that — everything ordered as rows in a spreadsheet — but I’ve found that its really easy to get confused, leading to discussions of whether that feature is 23 in the priority list or 24. Or maybe its 21.

    MoSCoW, which comes from the DSDM process gets around that problem by classifying at a high enough level that its actually useful. Plus, as Rob says, the customer can always create fine grained priorities when deciding between a specific set of features.

  5. John Roth Says:

    There’s another point about priorities that emphasizes the difference between Scrum and XP planning. In Scrum, you’re planning sprint by sprint. In XP, you’re planning a release at a time, and each release will usually have multiple iterations. MoSCoW works really well to front load musts into the early iterations, shoulds next and coulds last.

    When you’re done with the release planning, everything that’s in the first three categories should be in the plan, and if the estimates and velocity are at all accurate, they’ll all get done – at least if the feature set doesn’t change and the dev team doesn’t get hit with people being out.

    Front loading the iterations makes it really easy to manage scope: the least important stuff is at the end. Relative priority within category is completely irrelevant except at the tail end where you might want to drop nice-to-have features to meet the ship date.

    John Roth

  6. Anthony Bailey Says:

    siddharta: “I’ve found that its really easy to get confused, leading to discussions of whether that feature is 23 in the priority list or 24. Or maybe its 21.”

    I think it doesn’t matter much, since you work on the things at the top of the list. So leave it at 23 for now, and think harder about the ordering when it is more timely to do so.

    I guess I advocate using a lazily refined linearly ordered list as a simple representation of what one actually has, which is an ordering that is partial and full of small mistakes.

  7. JannetZika Says:

    Просматривая хентай секс мульты скачать ridiculously wild anal порно винтаж фото мультфильмы скачать 3d порно порно бесплатно офис порно износилование групового секса порно стариков онлайн порно ебут невест ранетки порно фото проститутки москвы анальный секс анальный секс женщина сверху безболезненный анальный секс нравиться анальный секс порноролики смотреть видео порно полнометражное оргия порно рассказ скачать порно site id страпон домины флеш порно аниме yandex порно голые красивые парни поддельные порнофото лезби бесплатно видео насколько приятен анальный секс поче мужчинам нравиться анальный секс Вот такие вот дела

  8. Bojana Novakovic Interview Says:

    A formidable share, I just given this onto a colleague who was doing a bit analysis on this. And he in truth bought me breakfast as a result of I found it for him.. smile. So let me reword that: Thnx for the deal with! But yeah Thnkx for spending the time to debate this, I really feel strongly about it and love studying more on this topic. If possible, as you develop into expertise, would you mind updating your blog with more details? It is extremely useful for me. Massive thumb up for this weblog post!

Leave a Reply