MoSCoW - is it a sensible way to prioritize requirements?

Back in the mists of time (some time in the last century) DSDM came up with a neat acronym for classifying the importance of requirements, MoSCoW - meaning a requirement was one of:

• Must-Have
• Should-Have
• Could-Have
• Won't Have (even if you Want it!)

The problem with this scheme has always been getting stakeholders to specify their requirements as anything other than Must-Have and Project Managers to resource their projects so that there's anything other than barely enough time for the mandatory requirements. Just like my old boarding school - if it wasn't compulsory it was forbidden. Many agile practitioners have concluded that schemes like this which give user stories a priority value or category, are not worth the effort - just get the product owner to identify the next most important stories and we'll prioritize the other requirements later. I sympathise with that view but on a previous project I needed a way to introduce the idea of a "scope range" for each release of the software, and to do that I redefined the meanings of the MoSCoW categories.

Firstly Must and Won't:

Must-have (this release): If this functionality is not available by the release date, the release will be delayed.
Won't-have (this release): If all the other functionality is complete before the release date, we'll release early rather than start this work.

Should-have and Could-have both mean they will be attempted for the release if there's time. The difference between them is whether our forecasting predicts that it is more or less likely that they will make it. Thus:

Should-have (this release): Our forecasting shows a greater than 50% probability that the functionality will be included.
Could-have (this release): Our forecasting shows a less than 50% probability that the functionality will be included.

I felt this was a stepping stone for the client, to move away from deterministic and towards probabilistic planning. The main problem with the approach was that I was re-using a scheme that already had a publicly available definition and so in a large organisation there was no guarantee people would be using the definitions I had introduced.

A better approach now is to look to schemes based on the cost of delay of requirements. This again emphasises the probabilistic nature of forecasting and uses flow data from the process to optimise costs.

Requirements, requirements, requirements

Is it possible to implement an agile project without overhauling your requirements process? I think not. The key economic benefits flow from agile methods ability to reduce "work in progress" compared to traditional methods [Anderson]. This means specifiers must take a much lighter approach to distant requirements and have much greater involvement, for example as "on-site customers" or product owners, in requirements currently being implemented.

[Anderson] Agile Management, Prentice-Hall (2003)

Traceability through a simple metamodel

When people start defining processes with total traceability between every aspect, the sight is often not very pretty! When traceability adds multiple layers of complexity it rarely pays for itself in terms of improved quality or maintainability.

This is one of the reason why we defined what we termed the "minimum metamodel" in the Better Software Faster book on agile development. The diagram shown here is this model in its simplest form. The questions traceability should answer are:

• How is this requirement tested?
• How is this requirement implemented?
• How is this part of the design tested?
• Why is this part of the design needed?

It's a useful starting point when defining the artifacts required in a software development process, and the references they should contain to enable these questions to be answered.

3 Types of Requirement

Priority-driven processes only work if you can model the process around task patterns for a single requirement. There is little point in prioritizing say, coding over testing, or design over specification, since all these activities must take place at some stage, even if they happen inside an activity that is called something else. But are all requirements the same (in the sense of using the same processes) or are some requirements more the same than others?!

Recently I was asked to advise on the requirements capture process for an organization wanting to apply agile techniques in a controlled environment. I came up with some slightly different names for types of requirement, though I think the concepts will be familiar to you if you've analyzed other software development methods. The requirements types (shortened to PCF) are as follows:

• Business problem statements (Problems)
• Solution contraint statements (Constraints)
• Solution feature statements (Features)

I've written elsewhere about FDD, which provides a very good process for managing and prioritizing features. However often projects applying processes like FDD do not pay enough attention to the other types of requirement that precede features.

Problems, for example, should identify issues in terms of a measurable aspect of the current solution and the degree to which a performance improvement would overcome it. Constraints express aspects of the solution that the current designers are not expected to change (though they should also state the rationale behind the constraint, and how and by whom it may be changed if justification exists). Only by considering all of these three types of requirement can the essential requirements of a system be captured.