The MoSCoW Prioritization
The MoSCoW Prioritization
Often, ideas or features to improve the pipeline come up in the middle of a project. Read about what questions to ask to see if switching gears is worth the effort.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
One of the hardest parts when it comes to implementing 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 have limited use for this project, we risk the project's success and our customer's satisfaction.
For example, one of your business analysts, John, comes up with a brilliant idea which he believes it should be reordered on top of the product backlog. One of your top developers, Jack, also stumbles 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 much that we should 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
Is our final solution useless if we don't ship this specific feature with our product? Are we going to have constant problems throughout 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 in order to include them.
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, even though it may 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.
Is this feature going to enhance the customer experience, but it won't affect the project goal at all if it won't get delivered? Will the development process continue to be successful although using that framework will help 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 in implementing them.
Is the project scope not affected 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.
Published at DZone with permission of Emmanouil Gkatziouras , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.