The MoSCoW Scale – From Russia With Love

In an Agile framework, the requirements for a software package are usually delivered to the stakeholders in increments. I’ve already written something about incremental delivery, so today I’ll talk about the rather important matter of order.

The order of these incremental deliveries is determined by the importance of each requirement. This way, a stakeholder gets their hands on the most important requirements first and the less important ones later on. This is also helpful for the development team to focus more on delivering the most crucial functionality of the project right off the bat.

A common method used to prioritize requirements is the MoSCoW approach.

‘M’ stands for ‘must have’, ‘S’ for ‘should have’, ’C’ for ‘could have’ and ‘W’ for ‘won’t have’.

A ‘must have’ would be a requirement that is fundamental for project success.  If any of the ‘Must’ features are not done, the project will be considered a failure. A ‘should have’ is something which is considered important but if it can be satisfied in other ways then it will only be included if possible.

A ‘could have’ is something which is nice to have, but not necessary. A ’won’t have’ requirement is a requirement that we at some stage decide to not implement right now, but maybe later.

Each and every business requirement is categorized using this approach.

This task eventually turns out be one of the most challenging parts of a project. Who decides what is a ‘must have’ or what is a ‘could have’? Instantly, one might deduce it should be the client as he/she is mostly familiar with the environment where the system will be implemented. In reality, if this is left solely in the hands of a stakeholder, everything would be pigeon-holed as a ‘must have’. This is definitely not feasible and entirely insensible. Believe me, it fast becomes like putting a little kid in a candy store; “What would you like honey?” “Can I have everything?”

When testing a system, I have to apply the same approach. The focus must reflect what was agreed in the requirements catalogue after applying the MoSCoW method. Testing is performed in parallel with development most of the time, so if the ‘must haves’ are developed first, then they would be the first to be tested. Clearly understandable, these requirements would be the first to be delivered. Usually the way project milestones are scheduled is based upon the ‘must have’ requirements and the estimated time it would take to develop them.

This also inflicts a certain amount of pressure for these ‘must haves’ to be fully functional and flawless. It is not just the order in which they are delivered that is affected, but also their importance within the whole product. A ‘must have’, because it is a requirement that the project cannot do without, is a far more crucial selling point than a ‘could have’ or a ‘should have’.  For ‘must haves’ I would normally spend more time thinking about different scenarios and loopholes to make sure that these modules are the most robust and rigid.

When a fixed budget is set for a project, the way the requirements are categorized using the MoSCoW method often raises discussions. If there is not enough time or money, something needs to be sacrificed. It is only natural to remove requirements that are less important and focus on the more important ones. In the end, if the product does not fulfill its purpose, it will never sell. The MoSCoW method is a dependable and trustworthy method to do so consistently.

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.