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!