Prioritizing Your User Stories with the MoSCoW Method

Whether you’re working on a small toy app just for fun or conquering the “Next Big Idea™”, writing and prioritizing your user stories should be your very first step. Prioritizing helps you figure out which tasks you should be working on first. If you’re working on a contract basis, prioritizing helps you communicate features with your client and remain on time or budget. You can use priorities to provide “flex requirements” which will get implemented should the time and budget permit, as opposed to “system critical requirements” without which the project is incomplete or unusable.

In this article, I’ll briefly explain what the MoSCoW method is, and how you can use it to prioritize your user stories.

User Stories

User stories are fundamentally just statements of functionality. Specifically, these user stores take the following form:

“The User Can __________.”

Where the ______ contains a statement of what the user can accomplish using your application.

An example of user stories for the Starship Enterprise™ from Star Trek™ might be the following:

• “The user can login to the application using a username and password”
• “The user can register a new account with the application.”
• “The user can view all new singularities in the local area network.”
• “The user can go on vacation in the holodeck.”
• “The user can beam from the ship to another location”
• “The user can wear a red shirt”

MoSCoW and That Weird Capitalization

Once our user stories are written, we can go back through and prioritize these using the MoSCoW method.

MoSCoW is an acronym for “Must, Should, Could, or Won’t” and the MoSCoW method involves changing the word “can” in your user story to one of the above operative words.

MUST

After writing your user stories, you’ll go through the list and find the most important and critical features. These are features that MUST be present for the application to be functional at all. As you go through the list, replace the word “can” in your user stories with the word “MUST” to indicate that the feature is a core feature.

Ex:

• “The user MUST login to the application using a username and password”
• “The user can register a new account with the application.”
• “The user can view all new singularities in the local area network.”
• “The user can go on vacation in the holodeck.”
• “The user MUST beam from the ship to another location”
• “The user can wear a red shirt”

In the above example, I’ve gone through the user stories and replaced the word “can” with the word “MUST” on all of the critical system components. Be honest here and make sure that you’ve properly classified something as a MUST — it may be tempting to say that every feature is necessary, but in fact there are very few.

When working on a contract basis, MUST tasks represent the tasks the must absolutely be completed or the contract is not valid.

SHOULD

Once you’ve completed the “MUST’s”, continue on with the “Should’s”. User stories that are a “SHOULD” are features that will most likely be available in the application, but that aren’t necessarily critical to system function.

Ex:

• “The user MUST login to the application using a username and password”
• “The user SHOULD register a new account with the application.”
• “The user SHOULD view all new singularities in the local area network.”
• “The user can go on vacation in the holodeck.”
• “The user MUST beam from the ship to another location”
• “The user can wear a red shirt”

Again, the “should’s” are features that you’re passionate about — perhaps you were tempted to put them on the “MUST” list but realized that they weren’t system critical.

When working on a contract basis, SHOULD tasks represent tasks that will likely be in the application barring any major requirements changes or major setbacks to budget or schedule. These features are the last features to get cut if cuts need to happen.

COULD

Describing a user story using “Could” represents a feature that is not critical nor necessary, but that would be “nice to have”. Could features represent usability or feature enhancements that aren’t necessary for the application to be released.

Ex:

• “The user MUST login to the application using a username and password”
• “The user SHOULD register a new account with the application.”
• “The user SHOULD view all new singularities in the local area network.”
• “The user COULD go on vacation in the holodeck.”
• “The user MUST beam from the ship to another location”
• “The user can wear a red shirt”

COULD tasks are tasks that may or may not be available in the application. These requirements are the most flexible, and if a time or budget concern arises these are the first tasks to be cut from the schedule.

WONT

Tasks described as “WONT” are tasks that will not be available or completed in the current version of the application. This does NOT mean that the features are gone forever — merely that they are not going to be on the schedule for the current iteration of the application.

Ex:

• “The user MUST login to the application using a username and password”
• “The user SHOULD register a new account with the application.”
• “The user SHOULD view all new singularities in the local area network.”
• “The user COULD go on vacation in the holodeck.”
• “The user MUST beam from the ship to another location”
• “The user WONT wear a red shirt”

It may be tempting to simply remove the WONT tasks from the list. However, keeping the WONT tasks on the list is a great way to document that an idea was considered and that it was purposely rejected for the current iteration.

If the “WONT” tasks are removed then, later on in the project, when someone asks “what about feature X?”, the team does not have any indication that the feature was even considered. By keeping the item on the list with a WONT designation, the team documents that the feature was considered and that it was purposely rejected.

PROs and CONs

The MoSCoW method is one that I’ve personally used with great success on a number of projects. That said, there are some negatives to consider when evaluating this method.

PROS

• Easily and Quickly documents requirements
• Ignores implementation details so they can be decided after further consideration.
• Effective way of communicating requirements with the team and clients.
• Provides prioritization in a fast and intuitive way — typically takes less than 30min to document and prioritize an entire project.

CONS

• No rationale for prioritization decisions is given.
• Does not document details of each story — those are left to later tasks.
• Limited to only 4 levels of priority — could be restrictive to some.

Having worked with many methods of task management and prioritization, I’ve found the MoSCoW method to be an excellent compromise — something that can be accomplished quickly, but still maintains a sufficient level of prioritization diversity.