Executive in wait

Prioritisation September 19, 2005

• One problem with requirements is that there are always too many of them.
• So there has to be some way of choosing which ones will be implemented in which versions of the product.
• The requirements need to be put into an order of desirability, in other words they need to be prioritised
• Decisions about prioritisation are complex because they involve many different factors and these factors are often in conflict with each other
• Also, as there are many stakeholders with different goals, it is difficult to reach agreement about priorities

Prioritisation Factors

• Minimise Cost of implementation
• Value to customer
• Time to implement
• Ease of technical implementation
• Ease of business implementation
• Value to the business
• Obligation to some external authority

Prioritisation Procedures
Requirement Priority Grading

• You can do a rough prioritisation and give each business event response a priority rating. Something like High, Medium, Low will work fine
• For example some people grade requirements by release or version number: R1, R2, R3…. The idea is that the R1 requirements are the highest priority and are intended to appear in the first release, the R2 in the second release and so on.
• If your progressive prioritisation using the above ideas still leaves you with more requirements than will fit into your budget, then you need to go into much more detail.

Prioritisation Spreadsheet

• You can use a spreadsheet to prioritise the requirements
• The %Weight is the agreed percentage importance of a factor
• You arrive at the percentage weight by stakeholder discussion and voting.
• The total percentage weights for all factors must be 100%
• In column 1 you list the requirements that you want to prioritise. These might be atomic requirements or they might be clusters of requirements represented by product use cases, product features or business event responses.
• Then for each requirement/factor combination you give a score out of 10