One of the adjustments an organization must make when moving from waterfall to agile (or, in my organization’s case, partially emulating agile) is the prioritization of requirements. Requirements analysis produces a list of user stories that can be, at least in theory, broken up into chunks to be developed in different iterations. Even if not executing an agile process, this effort by the product management team and/or requirements analysts allows the project manager the freedom to negotiate features in order to meet an organizational deadline.
While asking some stakeholders will only produce a range of “must have” to “really must have,” a more appropriate set of prioritization values is the MoSCoW method:
- Must Have
- Should Have
- Could Have
- Would Be Nice But Probably Won’t
The trick, it seems to me based on a curory explanation of this method, is determining which requirements to categorize at what value: and according to whom. The person providing a requirement is likely to argue for its significance, so perhaps a method of evaluating that allows for quantification of the percentage of the user base affected (or which personas) may be of use.