Prioritisation Analysis
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.
1. Prioritization Factors
Factors that commonly affect prioritisation decisions are some combination of:
- Minimise Cost of implementation (how much cost to develop?)
- Value to customer (how much does the customer want it?)
- Time to implement (how much time to deliver?)
- Ease of technical implementation (how technologically difficult?)
- Ease of business implementation (how organisationally difficult?)
- Value to the business (how much will the business benefit?)
- Obligation to some external authority (necessity to obey law?)
Not all factors are relevant to every project, and the relative importance of the factors is different for each project. And, within a project, the relative importance is not the same for all of the stakeholders. So, given this combinatorial complexity, you need some kind of agreed prioritisation procedure to provide a way of making choices. Part of that procedure is to determine when you will make prioritisation decisions.
2. When to prioritise
How soon should you make choices? The answer has to be as soon as you understand what you have to choose from. The more visible you make your knowledge, the more possibility you have to make and help others make informed choices.
2.1 Early
Using the Volere requirements technique, you start by doing a project blastoff to assess your level of knowledge about the contents of the first 8 drawers of the Volere template [Rob2]. You do a high-level context analysis and, using event partitioning, you partition it into business related chunks. At that point, because you have some identifiable pieces, you can do a rough prioritisation and give each business event response a priority rating. Something like High, Medium, Low will work fine. You can use the results of this prioritisation for deciding which parts of the business you will investigate first. Also you can use it, even at this stage, to guide you in version planning.
2.2 Progressively
When you start to write atomic requirements you should progressively consider whether you can prioritise them. If there are there any requirements that are obviously Low value, then tag them L. Use the idea of Customer Satisfaction and Customer Dissatisfaction [Par1], [Rob1] to help other people make choices.
Part of the reason for this progressive prioritisation is expectation management. We use the term requirements, and people often think that means once they are written down they will definitely be implemented. What we really mean are desires or wishes that we need to understand well enough to determine how and/or whether we can implement them. For example there might be a requirement that is really high priority but, due to a mixture of constraints, we cannot meet the fit criterion 100% [Rob1]. However we do have a solution that will fit 85%.
If we have been progressively talking about prioritisation throughout the project, people are able to accept the compromise without feeling as if they have been “had”. We prepare people for the idea that we cannot implement all the requirements, but there is no point in saying this just once. To effectively manage expectations we need to continue to mention the need for prioritisation and choice.
3. Prioritisation Procedures
Here are some procedures that you can use prioritise your requirements.
3.1 Customer Satisfaction/Customer Dissatisfaction
This concept was introduced by Pardee [Par1] as a way of helping people to make choices. Instead of saying “is this high, medium or low priority” he asks two questions: “On a scale from 1-5 how satisfied will you be if we implement this requirement” and “On a scale from 1-5 how dissatisfied will you be if we do not implement this requirement”. This helps people to make consider the requirement rather than just making a binary choice. You can use customer satisfaction/dissatisfaction ratings as input to determining the requirement priority grading.
3.2 Requirement Priority Grading
You can grade your requirement priority however it suits your way of working. A common way of grading requirements is High, Medium of Low. But you can use any other grading that suits you.
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.
But suppose that, after you have tagged the requirements by release you then discover that you have too many requirements in the release 1 category. At that point you need to prioritise the release 1 requirements into high, medium and low.
The idea of sorting the requirements into 3 categories is often referred to as triage and has been written about by many people in the software engineering field. Most recently see [Dav1] for a detailed discussion of applying the idea. In summary, triage is a term that comes from the field of medicine. When there has been a disaster that injures a number of people there are usually insufficient resources to treat all the patients. So the doctors need to categorise the patients into three groups:
- Those who will benefit from medical treatment
- Those who will live without treatment
- Those who will not survive
These groups roughly map to the idea of high, medium and low prioritisation categories. It is a powerful idea because it makes people realise that there are many more difficult prioritisation decisions in the world than prioritising requirements for a product. And, if you work as a team it is possible to arrive at a decision.
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.
3.3 Prioritisation Spreadsheet
You can use a spreadsheet to prioritise the “overflow” requirements. Ideally, especially if you have done a good job on progressive prioritisation, these requirements will fit into the Medium or would like if possible category. In other words you have been able to fit all the High priority requirements into your budget. If this is not the case then prioritise the High priority requirements and either drop the Medium and Low or tag them for future releases.
You can use the downloadable Volere Prioritisation Spreadsheet as a way of prioritising requirements. The spreadsheet contains some examples that you can replace with your own data.
The prioritisation Factors are one or more of the following (or any other prioritisation factors relevant to your project:
- Minimise Cost of implementation (how much cost to develop?)
- Value to customer (how much does the customer want it?)
- Time to implement (how much time to deliver?)
- Ease of technical implementation (how technologically difficult?)
- Ease of business implementation (how organisationally difficult?)
- Value to the business (how much will our business benefit?)
- Obligation to some external authority (necessity to obey law?)
On the spreadsheet I have limited the number of factors to four. If you are trying to manage more than four prioritisation factors it is very difficult, if not impossible to come up with an agreed weighting.
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. The score is assigned based on how much of a positive contribution do you think that this requirement makes to this factor. For example, for requirement 1we have assigned a score of 2 for the first factor because we believe that it does not make a very positive contribution to Value to Customer. On the other hand, the same requirement scores 7 because we believe it does make a positive contribution to our business. The score for minimising cost of implementation is 3 because we think this requirement will be relatively expensive to implement. And ease of implementation scores 8, to reflect that this requirement will be easy to implement.
For each score, the spreadsheet calculates a weighted score by applying the % weight for that factor. The priority rating for the requirement is calculated as the total of the weighted scores for the requirement.
You can use a variety of voting systems to arrive at the weights for the factors and the scores for each requirement. Of course the spreadsheet is merely a vehicle for making it possible for a group of people to review and arrive at a consensus for prioritising the requirements. By making complex situations more visible you make it possible for people to communicate their interests, to understand other peoples’ opinions and to negotiate.
[Dav1] Davis, Alan M The Art of Triage: A Report from the Trenches. University of Colorado Springs, 2002.
[Par 1] Pardee, William To Satisfy & Delight Your Customer. Dorset House, New York, 1996.
[Rob1] Robertson, James & Suzanne Mastering the Requirements Process. Addison-Wesley, 1999.
[Rob2] Robertson, James & Suzanne Volere Requirements Template. The Atlantic Systems Guild 1995-2009.
Download the Volere Prioritisation Spreadsheet