In order to ensure that a project can be of service to the organization in time, timeboxes are used. For example, the functionality with the highest priority should always be delivered within a timebox. If there is time and space left, then there will be room for functionalities with a lower priority. A timebox is a time interval in which an intermediate product is delivered. During the project, the precise functionality is refined further. Due to growing insights and changing circumstances, the specifications of a functionality can also change.

A timebox is prepared, in which must-haves, should-haves, and (possibly) could-haves are defined. This layout allows you to create room for manoeuvre without affecting the end time of the timebox. In other words, in the case of changing insight or emergencies, you will be able to re-prioritize. This may be at the expense of should-have and could-have system requirements. By applying MoSCoW, you make these choices explicit.

With this technique, you can keep constant focus on functional requirements with the highest priority, monitor your time and budget, and still be able to act when insights change. Using this technique enables you to give priority to the system requirements that give a company the most benefit, and lower the priority for requirements that were derived from situations that may never occur. This also makes systems simpler in design—something that improves their maintainability.

The classification of requirements and wishes based on the MoSCoW classification also helps users to visualize the support for a project within an organization. There are now authors who think that you should consider projects as clusters of micro-projects. Every micro-project is a requirement or a wish with a certain priority. In many projects, the support from stakeholders starts to crumble when people are confronted with changes. If a project includes many must-haves, this risk will be smaller than when it largely consists of would-haves.