Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.
Failing to get a grip on requirements can result in unintended consequences, including stakeholder power plays, unhappy and frustrated end-users, and angst over flip-flopping on requirements. Your team members may stress out over the need for last-minute implementation heroics, not to mention the wasted time and money of exploring or developing requirements that have changed or turned out to be irrelevant.
Prioritizing your requirements is not easy work. It requires team effort, often led by a business analyst, project manager, or ScrumMaster. It entails reviewing, evaluating, organizing, and deciding-tasks that are mentally and even emotionally challenging. What's more, you need to set priorities not once but continually throughout product development.
Let's look at some of the essential practices for prioritizing requirements.
At the start of the project, identify which stakeholders need to be involved in prioritizing requirements and at what points in the project. These stakeholders will vary by product and organization. Business or marketing owners are good candidates because they understand the business benefits and penalties for implementing the requirements. You should also consider including IT architects or developers, because they have a good understanding of the technical costs and risks.
Requirements evolve through exploration, invention, and iteration. If you are following an iterative (e.g., agile) process, you will revisit priorities at the end of each iteration and as part of planning for the next iteration. If you are following a more traditional development approach, it's best to set up milestones based on a time frame for delivering requirements to a predefined level of granularity. Because requirements are discovered and developed-not static elements passively waiting to be collected-you need to revise priorities continually.
Identify explicitly and precisely the factors you will use to analyze requirements priorities. In addition to business customer priority, consider costs, risks, and architectural dependencies. Costs should include not only development costs but also the business costs of not delivering a set of requirements.
Once you have laid out your criteria, you'll need to apply a ranking scheme to them. For example, you can classify each requirement as: essential, useful, or desirable; high, medium, or low priority, MoSCoW (must, should, could, or won't); or ranked in numerical order.
These ranking schemes are fine for starters, but they leave a lot open to interpretation. Stakeholders need to collaborate to arrive at clear, justifiable, and unambiguous definitions for each ranking level before applying them to the requirements.
I recommend that product owners (business sponsors, product managers) pick a scheme and then take a crack at defining each level. Next, we gather the other prioritizing stakeholders (business and technical) to review those draft definitions. Then they revise the definitions until everyone agrees on a meaning for each. I make a point of having the prioritizers reach closure on those definitions, using what I call "deft decision making" (described in the next section).
For example, in one project with regulatory implications, the definition of "essential" said that if the requirements were not implemented, the product would be in violation of external regulations, resulting in part of the business operations being slapped with a large penalty. All the prioritizing stakeholders understood the regulations enough to know which requirements would fall into the "essential" category. As stakeholders raised sets of requirements, they applied their ranking scheme and were able to prioritize the sets efficiently.
Deft Decision Making
The key to effective prioritization is to be clear about what your decision rules and decision process are. For example, a decision rule might be that a person in charge (such as the product owner) will make the final decision after