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.
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.
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.
" At a Glance: Other Prioritization Methods ," by Ellen Gottesdiener