• The initial vision is too costly or time-consuming to implement, we must scale back.
• The development effort will be done iteratively, and we must prioritize for the iterations (roadmap).
• Unfortunately, prioritization is also occasionally a proxy for controlling scope; the initial list of requirements represents more than the necessary features, so must be prioritized.

When you do need to prioritize requirements, don’t bother trying to put them in order. In the end, it doesn’t matter if one requirement should be ranked a little higher or lower than another requirement. You just want to figure out what to build. If you absolutely need 5 requirements fulfilled, ordering them 1-5 really doesn’t have any benefit. Determining that the 5 are absolutely necessary does.

You should use priority categories instead of an ordered list. The classic “high, medium, low” is easy, but doesn’t really map well to the real world. “Medium” is often just code for “not in this release, but not a bad idea”.

More realistically, you can use MoSCoW ratings (must, should, could and won’t have). You may need to further prioritize the “should” or “could” requirements as “high, medium, low” so the team knows what to work on first when the “musts” and “shoulds” are done (wishful thinking!). Remember – these categorizations must be based on the business objectives.

So, what do you do when there is disagreement about the prioritization? I’ll cover that in Part II.