Guideline: Prioritizing User Stories
This guideline explains how to prioritize user stories applying the MoSCoW rules.
Relationships
Main Description

Prioritizing stories

The prioritization of user stories and technical stories is driven by the stakeholders and facilitated by the development team. These two groups collaborate to prioritize the stories for a given release according to the stakeholders' business needs and the team's understanding of the highest architectural risks to be addressed. This prioritization allows the following to happen:

  • Both the stakeholders and the development team identify the critical functionality that the stakeholders need.
  • The development team highlights the essential stories that must be met if the team is to produce an application that will be useful to the stakeholders.

If a situation arises in which it appears likely that deadlines and effort estimates will constrain the development team's ability to deliver all known functionality, the stakeholders' prioritization of stories facilitates subsequent scope reduction. In such a situation, the stakeholders and the development team can work together to further negotiate and reprioritize remaining stories so that something of benefit can be produced by the deadline.

Scope prioritization is a powerful tool for businesses that need to react to, for instance, changing market conditions and new opportunities. As such, scope prioritization should recur several times during a release. Scope prioritization and scope reduction must continue to occur until the stakeholders and the development team have agreed on a baseline commitment.

Given that development time boxes (such as releases and iterations) are fixed, the deliverables from a time box may end up being less than was originally planned. If this is the case, it is important that all essential work is done within the time box and that only less-critical work is omitted. The method of ensuring that this is true is scope prioritization, which means prioritization of the stories to help with scope reduction.

Limiting functionality to meet an iteration deadline does not mean limiting quality. As with any software development endeavor, the development team strives to deliver an application fit for the business purpose: defect-free, user-friendly, and so on. The objective at the end of a development increment is to deliver a set of stories that will do useful work when the application is deployed into production.

The MoSCoW rules

The simple rules known as MoSCoW rules can be used to achieve clear prioritization of requirements. The development team can use these rules to lead the stakeholders and to formalize the way in which the they prioritize the stories for the system under development. The following table explains what the words in MoSCoW mean.

M Must have Essential stories that are fundamental to the system. Without them, the system will be unworkable and useless. The "must haves" define the minimum usable subset.
S

Should have

Important stories for which there is a workaround in the short term. These stories would normally be categorized as mandatory in a less time-constrained project, but the system will be useful and usable without them.
C Could have Stories that can more easily be left out of the increment under development.
W Want to have but won't have this time Valuable stories for which there is an appropriate alternative or a manual workaround. These stories can and will wait until later development.

Applying the MoSCoW rules

The MoSCoW rules provide the basis for decisions about what the project team will do during the overall time box (such as for a release), as well as within each nested time box (such as iterations). As new stories arise or as existing ones are defined in more detail, use the MoSCoW rules to decide how critical the stories are to the success of the current work. Review all priorities regularly throughout the project to ensure that they are still valid.

It is essential that not everything to be achieved within a time box is categorized as "must have." It is the lower-priority stories that enable the team to deliver on time, because they can drop those stories out of the current iteration if and when problems arise. It is possible that you may face a situation in which the following happens:

  • You have dropped all possible lower-priority stories so that all of the remaining ones are categorized as must-haves,and
  • Your assessment is that you will not be able to meet the deadline for all of those remaining stories.

To address this situation, you need to work with the stakeholders to do the following things:

  • If possible, reprioritize the remaining stories (according to the MoSCoW rules).
  • Re-negotiate reduced scope for this time box with the stakeholders, and adjust the remaining time boxes accordingly, moving some of the original must-haves to later time boxes.
  • If re-planning does not result in a viable plan, the project might no longer be viable as it stands and, in extreme cases, might have to be reconsidered by the stakeholders.

This mitigation strategy is designed to ensure that the stakeholders receive a usable application at the release deadline.