How to Triage Software Requirements Simply

Have you ever felt tension between the business community and Information Technology in a software requirements session?

The users rattle off requirements like a Gatling gun. Developers want to meet the user’s needs but realize they don’t possess magical powers.

At the same time, the sponsor has set a demanding project deadline.

Photo courtesy of

Photo courtesy of

Demand exceeds supply. It’s like trying to put 24 ounces of fluid in a 12 ounce coke bottle…you just can’t violate the laws of nature, no matter how hard you try.

Tough decisions must be made. How will the team prioritize the requirements?

Many teams rely on the old fashion process of rating the requirements with the vague and undefined categories of High, Medium, and Low. Over time, users often develop a bad habit of rating more and more requirements as High. The developers push back. It can turn into a fist fight.

The Simple Meaning of MoSCoW

Allow me to introduce you to another prioritization method which can be used for traditional as well as agile projects. It’s called the MoSCoW Prioritization. The upper case letters stand for:

  • Must. The requirement must be met. Without this feature, the project would be considered a failure.
  • Should. The requirement is important, but it’s not mandatory.
  • Could. The requirement is desired, but it could be postponed or eliminated. If there is adequate resources and time, build it.
  • Won’t. The requirement will not be implemented. It could be considered in a future project.

Although the categories are defined, MoSCoW has a similar problem of the High, Medium, and Low prioritization method. Users quickly learn to make everything an “M”. (I can see some of you smiling…you’ve run into this too, huh?)

How to Fine Tune Priorities

  1. Make sure the project goals are clear. The project team can select the requirements that best support the goals.
  2. Define prioritization criteria. When someone says a requirement must be met, how is this rating determined? For example, regulatory requirements would fall into the Must category. You might also work with your sponsor to define criteria such as cost, ease of implementation, business value, and strategic alignment.
  3. Select a decision maker for your requirement sessions. This person is typically a product owner, business leader or manager.
  4. Take unresolved priorities to the project sponsor for their final word.
  5. The developer should help the team to understand the level of effort required for requirements.
  6. If you have lots of requirements, see if you can group the requirements and prioritize at the group or feature level before prioritizing the individual requirements.

Who Should Be at the Party?

Carefully consider who should attend the requirement prioritization session(s). If you leave out key stakeholders, you will likely have to revisit the priorities later. Make sure you have appropriate development and testing resources present too.

Here are some potential candidates:

  • Business analyst. Business analysts may lead the requirements prioritization process.
  • Key stakeholders. Select key stakeholders that can represent stakeholder groups.
  • Decision maker. Again, select someone from the business who can make prioritization decisions. If there is a difference in opinion between the participants, this person makes the final call.
  • Lead Developer. It is important to have lead developer present who can speak to the level of complexity to design and develop the features and functions being requested.
  • Lead Tester. Invite the lead tester who can help ensure that the requirements are adequately defined and are testable. Testers can also help the stakeholders understand the level of effort required to test the required features and functions.

Final Thoughts

If this is your first time performing the MoSCoW Prioritization process, be sure to educate the participants on the process.

If you are under a tight schedule, talk with the decision maker before the first session. Seek to create a team approach where the business community works together with the Information Technology personnel. The goal is to prioritize the requirements in order to deliver the most valuable features and functions in the desired timeframe.

Question: What other prioritization techniques do you recommend? Why?

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *