Prioritizing Your Software Requirements, Part II

In Prioritizing Requirements, Part I, we covered the reasons to prioritize requirements and the basic technique. We’ll now address what to do when there is disagreement about prioritization.

Unfortunately, requirements prioritization exercises can degrade into arguments very rapidly. This is particularly true when there are conflicting requirements that each side feels they must have. The best way to avoid this type of emotional response is to discuss the facts – what will the impact to the business be if we don’t implement this requirement?

The only way to understand this impact for each requirement is to make sure each maps back to one or more business objectives. These objectives provide a measurable, quantitative impact for each requirement. Tracing back to business objectives allows you to rephrase the question from: “Which requirement do you want – System shall allow a player to play in more than one game at once. vs. System shall allow players to create and maintain teams of other players.” to “Which requirements is better for the business with respect to the objectives of this project?”

The trickiest thing here is setting up these relationships in the first place. If it is not clear how each feature enables the business objectives, it is certainly worth the time and effort to uncover the correct links to ensure that the features and requirements being implemented actually will help solve the problem!

The important thing here is that you are reframing the conversation from “what I want” to “why this feature/requirement will help achieve our goal.”

Happy prioritizing!

How To Prioritize Your Software Requirements, Part 1

One would think that since requirements are the necessary and sufficient list of behaviors needed to meet the business goals, prioritization is a non-issue. Everything is necessary, so why prioritize? Prioritization becomes an issue in the following ways:

• The initial vision is too costly or time-consuming to implement, we must scale back.


• The development effort will be done iteratively, and we must prioritize for the iterations (roadmap).


• Unfortunately, prioritization is also occasionally a proxy for controlling scope; the initial list of requirements represents more than the necessary features, so must be prioritized.

When you do need to prioritize requirements, don’t bother trying to put them in order. In the end, it doesn’t matter if one requirement should be ranked a little higher or lower than another requirement. You just want to figure out what to build. If you absolutely need 5 requirements fulfilled, ordering them 1-5 really doesn’t have any benefit. Determining that the 5 are absolutely necessary does.

You should use priority categories instead of an ordered list. The classic “high, medium, low” is easy, but doesn’t really map well to the real world. “Medium” is often just code for “not in this release, but not a bad idea”.

More realistically, you can use MoSCoW ratings (must, should, could and won't have). You may need to further prioritize the “should” or "could" requirements as “high, medium, low” so the team knows what to work on first when the “musts” and "shoulds" are done (wishful thinking!). Remember - these categorizations must be based on the business objectives.

So, what do you do when there is disagreement about the prioritization? I’ll cover that in Part II.