In most projects there are constraints on time and resources. There is rarely enough time to do everything. Therefore prioritization is required.
Prioritization is required on different levels.
- It is necessary to prioritize what is within and outside the scope of a product or the release of a product. Doing so will align what the project team will build and what the customer will expect to be delivered.
- It is also necessary to prioritize within a defined scope for planning and value realization purposes. A scope tends to change over time and often, it is necessary to make scope cuts to be able to keep deadlines.
Some key figures (Jones, 2007, Estimating Software Costs, MC Graw Hill):
- There is rarely full overview of requirements when product development is started. Often only 50% of the requirements are known
- Surveys suggest that a rough average of 20% of requirements are delayed to later releases in software projects
- Typically there is a 2% growth rate in requirements in software projects per calendar month
Below is a set of different criteria that can be used to define feature priority:
- In/out. Is a product feature in or out of scope
- “High, Medium, Low”. The attributes on each dimension is defined in the project but starting point can be:
- “High=important and urgent”,
- “Medium=important but not urgent”,
- “Low=not important and not urgent”
- “Rank ordering”. With this technique each main feature gets a rank. This method is efficient if there are a limited number of features.
- MoSCoW where the letters have the following meaning
- “Must”
- “Should”
- “Could”
- “Wont”
No matter how the priorities are being set it is important that the set of main features that are being prioritized form a consistent valuable product or release. Just selecting the highest priority features may not in itself ensure this.