The MoSCoW Prioritization

One of the hardest part when it comes to implement new ideas and features through the lifecycle of a project is making sure that the specific feature or the new framework that will be added, will play an essential part in the project’s success.

By implementing features that are hard to implement and are not as essential to the customer, or by adding tools to your stack, which require a certain expertise and time to invest in learning, but its uses are limited for this project, then we risk the project’s success and our customer will be unhappy.
For example one of your business analysts John comes with a brilliant idea which he believes it should be reordered on top of the product backlog. Also one of your top developers Jack might stumble upon a new tool which will help automate the testing process.

Is this new feature that John proposes as great and as essential as it seems for the client? Is the new tool that Jack proposes really needed, so that we will incorporate it in one of our sprint features for our next sprint?

A good and simple way to avoid waste is to use the MoSCoW Prioritization.
So here’s what MoSCow prioritization stands up for

  • M : Must have
  • S : Should have
  • C : Could have
  • W : Won’t have

Must have

Is our final solution useless if we won’t ship this specific feature with our product? Are we going to have constant problems through the product’s development lifecycle, which will risk its delivery, if we don’t use this specific tool?

If the above cases are satisfied then the feature or the non functional requirement is a must-have and we should work our way out in order to include them.

Should have

Is the feature important but not necessary for the customer to get started? Can we have a workaround if it doesn’t meet the delivery date? Is the product delivery not going to be affected if we won’t use this tool although it will save us time and effort?

If the above cases are satisfied then the feature or the non functional requirement is a should-have and we can find workarounds for that.

Could have

Is this feature going to enhance the customer experience but it won’t affect the project goal at all if won’t get delivered? Will the development process continue to be successful although using that framework will helps us speed things up?

If the above cases are satisfied then the feature or the non functional requirement is a could-have and it is not of high importance to have it. However if the must-haves and the could-haves are satisfied there is some real value on implementing them.

Won’t Have

Is the project scope not effected at all if we won’t implement this feature? Is the new tool introduced through our development process not used at all?

If the above cases are satisfied then the feature or the non functional requirement is a won’t-have and thus you don’t have to bother at all.

To sum up since the beginning of the project our main focus is on the must-have items. By satisfying them we can move to the should-have items. Finally we can tackle the could-have items.

All in all this way can helps us avoid waste and keep being efficient on resources needed.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s