Mission to MoSCoW

Nigel Mossman
Nigel Mossman | 13 October 2017

Mission to Moscow was a 1943 film  to put a positive spin on Soviet Russia and also the title of a song written by Mel Powell who was a member of the Glenn Miller Army Air Force Orchestra (recorded by several others including Benny Goodman); this post is really about prioritising work in an Agile project.

Many of you will know about MoSCoW; others not.  Generally people fall into three camps:

  • Never heard of it
  • Have heard of it and don’t properly understand it; often waterfall types.
  • Heard of it, some  love it; others hate it.

MoSCoW stands for:

  • Must have
  • Should have
  • Could have
  • Won’t have this time.  W used to stand for “Would have”; this was changed several years ago, I still meet people who haven’t caught up!

MoSCoW was invented by Dai Clegg, of Oracle UK Consulting and was used for the CASE Method Fast-Track, in the early nineties.  It was picked by DSDM®  in the mid-nineties is most widely associated with DSDM® (and remains the recommend prioritisation method in DSDM®/AgilePM®).

MoSCoW can be applied at to project, increment or timebox (sprint) level.    The prioritising team (which ought to include business stakeholders) determines which requirements are:

  • Must have – the deliverable is useless if this work is omitted
  • Should have – highly desirable but could live without it
  • Could have – nice to have, the icing on the cake.
  • Won’t have this time – excluded from the current planning horizon.

For the planning horizon in question, the Must requirements ought to represent no more than 60% of the available resource.  Should and Could have items  take 20% each.  If a project becomes tight for time features are sacrificed from the Could and Should have requirements, thus preserving the Must have items (which in DSDM® we refer to as the Minimal Usable SubseT; other methods refer to MVP, MSP etc).

To use the technique correctly teams have to be brutal.  If a requirement can be achieved by another way (even if it’s a painful) then it is, at best, a Should.   The  DSDM® Handbook suggests starting with all requirements as Won’t Have and argue them up to Could, Should or Must.

As noted earlier, Won’t have this time replaced  Would have which used to lead to the expectation that a requirement might make it into the delivery when in fact it that was never the case.  The change to Won’t have is (in my view) very sensible.   Unless a requirement has been dropped completely, it remains on the backlog for selection at some future planning event.  For example, a requirement might not be needed for the first increment but may well be a Could or Should or Must in a later increment.

Those who dislike MoSCoW say that once you have grouped requirements into Must and Should and Could have requirements you have no further mechanism to refine the delivery order; what is the most valuable Must have requirement?

This is resolved by teams creating a Delivery Plan (i.e. placing stories as candidates into Sprints/Timeboxes/Iterations etc).  This is an important part of planning as it both confirms the work might fit into the timeline/engineer mix and identify previously hidden dependencies.  There are several ways to achieve this:

  • Business Value – Which requirements deliver the most business value?  This might be a technique applied to a project concerned with systems improvement rather than a greenfield development.
  • Uncertainty and Risk Management (subtly different; our Adapt2.0 framework offers guidance in these areas) – the Must have items might be delivered in an order that mitigate uncertainties or risks.   This might be applicable when the team is trying to create new products or technologies.
  • Process Flow – building out features that support the development of a process flow – in effect building a thin slice through the system as a starting point for incremental delivery.
  • Weighted Shortest Job First (WSJF) from  Scaled Agile Framework® (SAFe®), this creates a mathematical model for prioritisation.  While I have my reservations about this (as it allows a level of gamification by participants) it does create a way ordering requirements when in theory all are equal.

You could use any one of the above techniques to order the entire requirements list without using MoSCoW; however, a “line” has be drawn and that’s often too simplistic and as anybody who’s worked with large lists of requirements will know, evaluating requirements is a slow process.  MoSCoW can and does provide a method to identify the most valuable items before determining the optimal delivery order.

MoSCoW has been around a long time (not as long as the song), it remains a relevant and useful Agile planning tool irrespective of Agile method.