Now that we have developed a list of requirements that have been categorized based on their importance to the client or user, we need to determine how best to actually develop our system. 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 of the 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, with the addition of improved 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 incredibly difficult to review and rank each requirement on a scale from 1 to N. And as you’ll learn when you discuss prioritizations with your team, each person will bring their own values and experiences to this decision, which very likely means they will have differing opinions on high and low priorities.

Prioritizing Requirements

To prioritize our 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 member of the team then 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 questions they have about the requirement that once answered might allow them to better rank it.

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

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

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

This method of reviewing our requirements and evaluating their priority in the development process also provides us with a chance to identify requirements that we might have missed. This often arises because, as a team, we begin to identify and question the assumptions we may have made that led us to categorize and prioritize a requirement in 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 come across 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 are careful to consider how our prioritization overlaps between the different categories.

In practice, we try to keep our overlap between categories to one bin. That is, 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 the process of 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 how to categorize and prioritize requirements. If they are bad representations, explain why.

Review Questions