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.
Proper Participation
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.
Clear Criteria
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 hearing discussion among the prioritization community; an alternative might be that decisions require consensus (unanimous agreement) by the group.
A decision process is a protocol that describes how any decision is to be proposed, who reviews it (and how), and how the group will reach closure on the decision. Practice these rules and process them as a project community before you start prioritizing.
This approach is also effective in mitigating the risk of a major project contaminant: certain stakeholders playing politics or undermining team judgment. For more on decision rules and decision making, see "Decide How to Decide: A Collaboration Pattern" and my book Requirements by Collaboration.
Coherent Clusters
Once you have your people, criteria, and decision-making process in place, you need to organize your requirements so that you can prioritize them. How you organize requirements can vary based on how you have represented them or by the software domain you're targeting.
The general idea is to group similar requirements into logical chunks of functionality. For example, event-response pairs can form feature groups or clusters. You might organize cohesive use cases into use-case maps or packages to form clusters of requirements. If you work with stories, you can group them into epics, themes, or features. Or, if your product domain is data-centric (e.g., storing, querying, and reporting information), you might cluster requirements by data groups.
"Be sure to include nonfunctional requirements: external interfaces (e.g., feeds to and from other systems, subsystems, or devices), design and implementation constraints, and quality attributes (e.g., system performance, reliability, and response time). Try to limit the total number of clusters to thirty or fewer."
Also be sure your clusters reflect interdependencies. Ask yourself, can one or more requirements be implemented independently? Must we implement some requirements together? If there are dependencies but the requirements don't have to be implemented together, keep them separate but identify them as interdependent. This structure will help you sequence your releases.
Dependency analysis may alert you to architectural dependencies that you need to understand in order to decide what to release when. It also is essential for successfully managing incremental releases. Remember that interdependencies are often based on data and the state of key business data, so include a high-level description of dependencies in your initial analysis-modeling efforts.
Summary
Know where and when to put your energies by prioritizing requirements. After getting an overall view of the requirements landscape, organize your requirements into workable chunks and revise your priorities as you learn more about them. Systematically deciding who, when, and how requirements will be prioritized not only establishes a healthy team culture but also makes good business sense.
Further Reading
" At a Glance: Other Prioritization Methods," by Ellen Gottesdiener
