As a Business Analyst, one of the key features of a requirement is the priority.
I guess it’s important to state up front that all requirements are important. If they weren’t, we wouldn’t even bother documenting them, thus removing the need to even assign a priority. But having a priority is useful to help deliver the most valuable features first.
An example to illustrate this point could be a search feature. A high priority feature might be to provide the ability for a user to search for an item:
As an end user, I want to search for an item, So that I can quickly find the item I am looking for
A lower priority item could be the ability to filter the resulting search items:
As an end user, I want to filter the list of returned items, So that I can narrow down the scope of the returned list to help me find an item faster
If we assume that being able to search is a key feature of the system, we would assign a higher priority to that feature, so the development team can understand what work to place before others.
How?
One of the more popular ways to specify a priority (and the one I personally recommend) is using the MoSCoW method. The o’s are really just there to make it into a word we can reasonably say. The four upper case characters essentially define the 4 levels of priority we can assign to a requirement:
- Must have
- Should have
- Could have
- Want to have (or Won’t have, depending on who you ask..)
What we usually find however, is that people don’t really understand the true meaning of MoSCoW. This invariably leads to most, if not all of the requirements being labelled as “must have”.
Must have
Must have requirements are essential to the success of the project. If any “must have” requirement isn’t met, then the project is deemed a failure.
Another way to approach a must have is to ask the question:
if we can’t deliver this story, should we cancel the project?
If the answer is yes, then it’s a must have requirement. If the answer is no… then maybe it might be better represented as a should have.
It might be useful to think of the word “Must” as an acronym for “Minimal Usable SubseT” before you make all of the user stories in a demand must have priorities. Think about what the solution really needs to implement in order for it to add value to the user. Those should be your “must have’s”. Ideally must have requirements will form the majority of the requirements for any particular demand.
Should have
Should have requirements are important to the success of a project, almost equally as important as a must have. The difference being that the end solution should still be delivered if for any reason an S requirement couldn’t be delivered.
I think the lack of “should have” requirements stems from a lack of trust between those with the want, and those delivering the want. Product Owners may assume that their should’s won’t be delivered, and so force everything through as a must have requirement in order to guarantee everything that they want gets delivered.
I think this view is wrong, the true definition of a should have requirement is something that is still essential to a solution, but that the solution still works without them. The development team should also understand what a product owner means when they say a requirement is a should have, if not how can we expect to receive requirements with anything other than a “must have” priority?
Could have
Could haves are again a drop down in priority. Where we would view meeting all must haves and should haves as a project success, the delivery of could haves are the “icing on the cake”. They usually add value to the user, as opposed to having a negative impact if left out.
Want to have (or Won’t have)
Requirements with this level of priority are effectively deemed out of scope for the current phase of development. They could however, be important requirements for a later phase of development. At that time, the requirement should be re-scoped as per the priority for that phase.
It is useful to define these requirements to effectively scope the boundary of the project, as well as to ensure future requirements are documented.
Tips
- Ensure all interested parties understand what each priority means (Warning — this may require a shift in mindset).
- Make all requirements “Want to Have”. Increase the priority when you can justify doing so.
- Ask the question “If we don’t deliver this Must Have, should we cancel the project?”.
- Is there a manual work around? If so, it may not be a “Must Have”.
Conclusion
If your demand consists of 10 user stories, each of which is classified as a “Must Have” requirement, consider the usefulness of prioritising them at all.
MoSCoW gives us a great way to define priorities, using natural language we can all relate to. Let’s use it as it was intended, to deliver great products!