DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

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.

Emmanouil Gkatziouras user avatar by
Emmanouil Gkatziouras
CORE ·
Apr. 25, 18 · Analysis
Like (10)
Save
Tweet
Share
6.20K Views

Join the DZone community and get the full member experience.

Join For Free

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

Must Have

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.

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, 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.

Could Have

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.

Won't Have

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.

Non-functional requirement

Published at DZone with permission of Emmanouil Gkatziouras, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Is a Kubernetes CI/CD Pipeline?
  • What Is Policy-as-Code? An Introduction to Open Policy Agent
  • Kotlin Is More Fun Than Java And This Is a Big Deal
  • The Future of Cloud Engineering Evolves

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: