MoSCoW prioritization

from Wikipedia, the free encyclopedia

The Moscow prioritization is in the range of a method, project management is used and allows the project manager, the implementation of the requirements based on their importance and their impact to prioritize. The MoSCoW prioritization has its origin in the Dynamic Systems Development Method .

MoSCoW is an acronym and stands for:

  • M - Must have (absolutely necessary)
  • S - Should have (should be implemented if all must requirements can still be met)
  • C - Could have (can be implemented if the fulfillment of higher-quality requirements is not impaired)
  • W - Won't have (not implemented this time, but reserved for the future).

The lower case letters in the acronym are only used for better legibility and have no other function.

definition

Must

Must describes requirements that are essential for the project and are non-negotiable. Failure to implement it in whole or in part would lead to the failure of the project. Requirements of this kind are summarized in the project timebox . MUST is also an acronym - Minimal Usable SubseT - and stands for minimum requirement .

Should

Although should requirements are not critical to the success of the project, they are highly relevant and should be taken into account in the project implementation , provided that the must requirements are not impaired . Should requirements can often be implemented in different ways.

Could

Could requirements are of little relevance and are often referred to as nice to have . They are only taken into account when capacities are available in addition to the priority processing of must and should requirements. But Could requirements should not be ignored across the board. Often, a few easy-to-implement Could requirements can generate not inconsiderable added value with minimal additional development costs.

Won't

Won't requirements have the lowest priority for the current project or the current planning phase. However, and this is one of the greatest advantages of MoSCoW , the classification as Won't shows that the requirement is professionally and / or technically important, but not time-critical. Requirements classified in this way will not be forgotten and will be prioritized again for planning the next release.

A good won't list has three key effects:

  1. No stakeholder has to "fight" for the inclusion of requirements
  2. When considering future requirements, current ones are also reconsidered
  3. When the designers see the long-term planning, they can make arrangements for later implementation in the current implementation

The advantages of the MoSCoW prioritization method are that, in contrast to a simple numerical 1 to 3 prioritization, it can be clearly and comprehensibly defined which requirements are time-critical and have the greatest business impact . Functional as well as non-functional requirements are taken into account.

Criticisms

This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.

Many also refer to a nice-to-have requirement (could) as an extension or delicacy and argue that, by definition, this is no longer a requirement and should no longer be classified as such.

The following points oppose this:

  1. Since the priorities of requirements often vary quite dynamically, it makes sense to continue to treat the Could requirements as correct requirements. Also Could -Anforderungen provide an important contribution. Only this is not critical to the success of the project or product.
  2. Iterative software development also often results in a change in priorities. As a result, Could requests can become should requests.

swell

literature

  • Iris Pinkster, Bob van de Burgt, Dennis Janssen, Erik van Veenendaal: Successful Test Management 2nd ed. Springer Verlag, 2004, ISBN 3-540-22822-5