ttmind

Main Navigation

ttmind
  • jim-jams
  • Tech
  • Positive
Login

Login

Facebook Google

OR

Remember me Forgot password?

Don't have account? Signup here.

Sort by Categorys

.Net

PHP

Java

JavaScript

Database

Server

Client Side

Tools

Artificial Intelligence

Cloud

Hybrid Development

Event

Smart City

Education

Security

Scrum

Digital Marketing

APP Development

Business

Internet

Simulation

Art

Network

Microservices

Architecture

Technology

Leadership

    Top Articles

  • How Does Social Media Bring People Together?
    TTMind Author
  • How to read appSettings JSON from Class Library in ASP.NET Core
    Anil Shrestha
  • Printing Support In Asp.Net Core
    TTMind Author
  • HOW TO EXTRACT TEXT FROM IMAGE USING JAVASCRIPT (OCR with Tesseract.js)?
    Prakash Pokhrel
  • Images Upload REST API using ASP.NET Core
    Prakash Pokhrel
  • Tech
  • About Us
  • Contact Us
  • TechHelp
  • PositiveHelp
  • Jim-Jams Help
  • Terms & Conditions

© Copyright ttmind.com

Main Content

MoSCoW prioritization for Projects or Products

Scrum Agile Software Development about 7 years ago || 8/30/2018 || 3.6 K View

  • Hide

Nowadays I can see a lot of software company are focusing in Agile Project Management, even maximum company have focused on product development too, so to achieve successful delivery there is technique called as MoSCoW prioritization, which I think can help a lot for DevOps team as well as a team who even work in old development methodology too.

So before diving into MoSCoW prioritization it's good to know what is it, so a definition from Wikipedia is; 

"The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis".

The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won't have), with the interstitial Os added to make the word pronounceable. While the Os are usually in lower-case to indicate that they do not stand for anything, the all-capitals MOSCOW is also used.

It Can be applied to 

  • Products, 
  • Requirements, 
  • Tasks, 
  • User Stories, 
  • Acceptance Criteria And 
  • Tests

So for prioritization of Requirements can be done with MoSCoW like


Mo => Must Have, 

  • Represent requirements that are guaranteed to be delivered.

S => Should Have, 

  • Represent requirements that are expected to be delivered.

Co => Could Have, 

  • Represent requirements that are desirable, but less important than Should Haves.

W => Won't Have, 

  • This time Represent requirements that won't be delivered.

Must Have

  • No more than 60% effort
  • Delivery Guaranteed
  • Minimum Useable Subset

Should Have

  • 20% effort
  • Expected
  • Work around difficult/Costly
  • These requirements should be left out as a last resort to keep the project on track.

Could Have

  • 20% effort
  • Possibly
  • Workarounds easy/cheap
  • The Could haves represent the requirements for which workarounds are easy and fairly cheap, and could be left.

Wont Have

  • 0 % effort
  • The won't haves are requirements that we won't have this time.
  • Maybe next time
  • Out of Scope for this time frame

Note:- MoSCoW prioritization is only meaningful within a given time frame. 

A must have requirement for the overall project may not be a Must Have for the first increment or release. A Must Have requirement for an increment could be a Should or Could for the first or Second time box of that increment.

The MoSCoW technique is designed to allow for delivery for the Minimum Usable Subset to be guaranteed. As a rule of thumb, the Must Haves should not represent more than 60% of the effort.

The Should Have and Could Have represent 20% each. This equates to 40% contingency, which will allow for even the most optimistic estimates. This means that firstly the Coulds and then Shoulds could be dropped to enable a time box to complete on time. 

There needs to be continuous review of priorities throughout the project, as a result of any change in understanding of depth and detail. Although the minimum usable subset is guaranteed, it's expected that most projects will deliver the Shoulds, and indeed, some of the Coulds. 

Current best practice suggests that delivering the Must and Shoulds ought to satisfy the business case, although some organizations build their business case on just the Musts.

Delivering the Coulds is always seen as a bonus, and only delivering the Must is considered the worst case scenario. A few more details can be found in Quora too https://www.quora.com/In-Agile-what-is-the-MoSCoW-prioritization-technique

Hope it helps, if some searching for way how to move for successful delivery of Project or Product.

  • 2
  • 0
  • 0
    • Facebook
    • Twitter
    • Google +
    • LinkedIn

About author

Alok Pandey

Alok Pandey

Love to share what I know.

Reset Your Password
Enter your email address that you used to register. We'll send you an email with your username and a link to reset your password.

Quick Survey