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.
|