Now that we have developed a list of categorized requirements based on their importance to the client or user, we must determine how to implement them. That is, we need to rank our requirements based on their priority. While categories based on the MUSCOW method provide a sense of importance and allow us to know which requirements form the minimal viable product, prioritization gives us a sense of when things should be developed.

Of course, this is easier said than done. Imagine, for example, that you were developing a new and improved Facebook from scratch. The goal is to produce software that does everything the existing Facebook platform does but with data management, data security, privacy settings, and facial recognition (for logging in).

If you were to rank each requirement from 1 to N (where N is the total number of requirements; 1 has the highest priority, and N has the lowest priority), which requirement would be ranked number 1? Why?

Which requirement would be ranked number 2? Why?

The point is, if you have a lot of requirements, it becomes difficult to review and rank each requirement on a scale from 1 to N. As you’ll learn when you discuss prioritizations with your team, each person will bring their values and experiences to this decision, which very likely means they will have differing opinions on high and low priorities.

Prioritizing Requirements

To prioritize requirements, we move away from ranking each on a scale from 1 to N. Instead, we bin our requirements. More specifically, we give each requirement a rank of 10, 20, 30, 40, or 50, where 10 has the highest priority, and 50 has the lowest priority. This allows us to review each requirement efficiently and prevents arguments about whether or not, for example, our requirement should be ranked 10th or 11th in the full list of requirements.

To determine which bin our requirement will fall into, each requirement is read aloud, one at a time. Each team member jots down the rank they believe makes sense for the requirement that has just been read, and some notes on why they’ve made this decision. Each member might also record any questions they have about the requirement.

Once everyone has had a chance to jot down their rank, assumptions and questions, the ranks are shared and discussed.

If everyone on the team has ranked a requirement the same, what should you do?

If everyone on the team has ranked a requirement differently, what should you do?

Reviewing our requirements and evaluating their priority in the development process allows us to identify requirements we might have missed. This often arises because, as a team, we begin to question assumptions that led us to categorize and prioritize a requirement the way we did.

Categorization & Prioritization

Before we move on, we probably should consider our categorizations and prioritizations. Since every project is different, we may experience situations where our musts have been prioritized using 10s, 20s, and 30s, and others where musts are prioritized only with 10s and 20s. This is perfectly fine, so long as we consider how our prioritization overlaps between the different categories.

In practice, we try to keep our overlap between categories to one bin. If our musts were prioritized with 10s, 20s, and 30s, we might prioritize our shoulds with 30s, or 30s and 40s, or 30s and 40s and 50s, or 40s, or 40s and 50s. In the first three cases, our shoulds and musts overlap at priority 30. In the final two cases, they don’t overlap at all.

Why do we do this? We do this because when we begin evaluating the logical flow of our requirements, having at most one bin of overlap will make that process much easier.

Activity: Evaluating Categories & Priorities

Consider each of the following diagrams that describe how a set of requirements might be categorized and prioritized. Your job is to review each and determine if they are good or bad representations of categorizing and prioritizing requirements. If they are bad representations, explain why.

Review Questions