Prioritization

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 categories are typically understood as:

Must have

Requirements labelled as Must have are critical to the current delivery time-box in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must have, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered an acronym for the Minimum Usable Subset.

Should have

Requirements labelled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.

Could have

Requirements labelled as Could have are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.

Won’t have (this time)

Requirements labelled as Won’t have, have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won’t have requirements are not planned into the schedule for the next delivery timebox. Won’t have requirements are either dropped or reconsidered for inclusion in a later timebox.

Bug priorities

Priority Classification Description When to fix
1 Critical defect The defect affects critical functionality or critical data. It does not have a workaround immediately
2 Major defect The defect affects major functionality or major data. It has a workaround but is not obvious and Allign with team, same Sprint or next is difficult
3 Average defect The defect affects minor functionality or non-critical data. It has an easy workaround Next Sprint
4 Minor defect Cosmetic defects When time allows