|Chapter 10: MoSCoW Prioritisation|
10 MOSCOW PRIORITISATION
In a DSDM project where time has been fixed, it is vital to understand the relative importance of the work to be done in order to make progress and keep to deadlines. Prioritisation can be applied to requirements/User Stories, tasks, products, use cases, acceptance criteria and tests, although it is most commonly applied to requirements/ User Stories. (User Stories are a very effective way of defining requirements in an Agile style; see later chapter on Requirements and User Stories for more information.)
The use of MoSCoW works particularly well on projects. It also overcomes the problems associated with simpler prioritisation approaches which are based on relative priorities:
The specific use of Must Have, Should Have, Could Have or Won’t Have this time provides a clear indication of that item and the expectations for its completion.
10.2 The MoSCoW Rules
10.2.1 Must Have
These provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. These may be defined using some of the following:
Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement. If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement. Categorising a requirement as a Should Have or Could Have does not mean it won’t be delivered; simply that delivery is not guaranteed.
10.2.2 Should Have
Should Have requirements are defined as:
One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected.
10.2.3 Could Have
Could Have requirements are defined as:
These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. When a problem occurs and the deadline is at risk, one or more of the Could haves provide the first choice of what is to be dropped from this timeframe.
10.2.4 Won’t Have this time
These are requirements which the project team has agreed will not be delivered (as part of this timeframe). They are recorded in the Prioritised Requirements List where they help clarify the scope of the project. This avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around. Won’t Haves can be very powerful in keeping the focus at this point in time on the more important Could Haves, Should Haves and particularly the Must Haves.
10.3 MoSCoW Relating to a Specific Timeframe
In a traditional project, all requirements are treated as Must Have, since the expectation is set from the start that everything will be delivered and that typically time (the end date) will slip if problems are encountered. DSDM projects have a very different approach; fixing time, cost and quality and negotiating features. By the end of Foundations, the end dates for the project and for the first Project Increment are confirmed.
It is important that the bigger picture objectives (completion of the Project Increment and delivery of the project) are not forgotten when working at the Timebox level.
10.4 Ensuring effective prioritisation
10.4.1 Balancing the priorities
When deciding the effort allocated for Must Have requirements, remember that anything other than a Must Have is, to some degree, contingency, since the Must Haves define the Minimum Usable SubseT which is guaranteed to be delivered.
This spread of priorities provides enough contingency to ensure confidence in a successful project outcome.
Figure 10a: MoSCoW – balancing priorities
In some circumstances the percentage of Must Have effort may be significantly less than 60%. However this can be used to the benefit of the business, by providing the greatest possible flexibility to optimise value delivered across a larger proportion of Should Haves.
10.4.2 Agreeing up front how priorities will work
DSDM defines what the different priorities mean – the MoSCoW Rules. But whereas the definition of a Must Have is not negotiable, the difference between a Should Have and a Could Have can be quite subjective. It is very helpful if the team agree, at the start of their project, how these lower level priorities will be applied. Understanding in advance some objective criteria that separate a Should Have from a Could Have and ensuring that all roles on the project buy into what has been agreed can avoid much heated discussion later. Look for defined boundaries that decide whether a requirement is a Should Have or a Could Have?
Ideally this agreement is reached before the requirements are captured.
10.4.3 When to prioritise
very item of work has a priority. Priorities are set before work commences and the majority of this prioritisation activity happens during Foundations. However, priorities should be kept under continual review as work is completed. As new work arises, either through introduction of a new requirement or through the exposure of unexpected work associated with existing requirements, the decision must be made as to how critical it is to the success of the current work using the MoSCoW rules. When introducing new requirements, care needs to be taken not to increase the percentage of Must Have requirement effort beyond the agreed project level. The priorities of uncompleted requirements should be reviewed throughout the project to ensure that they are still valid. As a minimum, they should be reviewed at the end of each Timebox and each Project Increment.
10.4.4 Discussing and reviewing priorities
Any requirement defined as a Must Have will, by definition, have a critical impact on the success of the project. The Project Manager, Business Analyst and any other member of the Solution Development Team should openly discuss requirements prioritised as Must Have where they are not obvious Must Haves (“Without this would we cancel the project/increment?”); it is up to the Business Visionary or their empowered Business Ambassador to explain why a requirement is a Must Have.
10.5 Using MoSCoW to Manage Business Expectations
The MoSCoW rules have been defined in a way that allows the delivery of the Minimum Usable SubseT of requirements to be guaranteed. Both the Solution Development Team and those to whom they are delivering share this confidence because the high percentage effort of Shoulds and Coulds provides optimum contingency to ensure delivery of the Must Haves.
10.6 How does MoSCoW Relate to the Business Vision
10.6.1 The Business Sponsor’s perspective
The starting point for all projects is the business vision. Associated with the business vision are a set of prioritised requirements that contribute to delivery of the vision. Also associated with the business vision is a Business Case that describes the project in terms of what value it will deliver back to the business. Depending on the organization, this Business Case may be an informal understanding or it may be defined formally, showing what Return On Investment (ROI) is expected in order to justify the cost of the project.
10.7 Making MoSCoW Work
Requirements are identified at various levels of detail, from a high-level strategic viewpoint (typically during Feasibility) through to a more detailed, implementable level (typically during Evolutionary Development). Highlevel requirements can usually be decomposed to yield a mix of sub-requirements, which can then be prioritised individually. This ensures the flexibility is maintained, so that if necessary, some of the detailed less important functionality can be dropped from the delivered solution to protect the project deadline.
10.8 Tips for Assigning Priorities
1. Ensure that the business roles, in particular the Business Visionary and the Business Analyst, are fully up to speed as to why and how DSDM prioritises requirements.
2. Consider starting with all requirements as Won’t Haves, and then justify why they need to be given a higher priority.
3. For each requirement that is proposed as a Must Have, ask: ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project; there is no point in implementing a solution that does not meet this requirement’, then it really is a Must Have. If not, then decide whether it is Should Have or a Could Have (or even a Won’t Have this time)
4. Ask: ‘if I come to you the night before Deployment and tell you there is a problem with a Must Have requirement and that we can’t deliver it – will you stop the Deployment?’ If the answer is ‘yes’ then this is a Must Have requirement. If not, decide whether it is Should Have or a Could Have.
5. Is there a workaround, even if it is a manual one? If a workaround exists, then it is not a Must Have requirement. When determining whether this is a Should Have or a Could Have requirement, compare the cost of the workaround with the cost of delivering the requirement, including the cost of any associated delays and any additional cost to implement it later, rather than now.
6. Ask why the requirement is needed – for this project and this Project Increment.
7. Is this requirement dependent on any others being fulfilled? A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of a Should Have or Could Have not being delivered.
8. Allow different priorities for acceptance criteria of a requirement.
9. Can this requirement be decomposed? Is it necessary to deliver each of these elements to fulfil the requirement? Are the decomposed elements of the same priority as each other?
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) is primarily used to prioritise requirements, although the practice is also useful in many other areas. On a typical project, DSDM recommends no more than 60% effort for Must Have requirements on a project, and a sensible pool of Could Haves, usually around 20% effort. Anything higher than 60% Must Have effort poses a risk to the success and predictability of the project, unless the environment and any technology is well understood, the team is well established and the external risks minimal.