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

“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

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

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

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

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

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

PROS

  • 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

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

Written by

Entrepreneur. Engineer. Educator.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store