This article is the first in a series on prioritising requirements. It explores why it is critical to project success to prioritise requirements, why it can be unsuccessful and describes two technique to achieve consensus.
All business analysts must understand how to prioritise requirements and why is it important to prioritise requirements.
Table of Contents
Why Prioritise Requirements ?
On most projects of reasonable complexity, there is a limited budget and the budget must be wisely targeted to maximise value and minimise costs. Prioritisation provides transparency to the business and allows them to make informed decisions when deciding on the scope of the project.
In other words, they will understand where the money will be spent and that it is spent on the most critical requirements. This enables an informed decision on the initial scope of the project and whether there should be subsequent phases. This is critical for agile projects where there are many releases of code or increments and the content of each must be agreed.
As the project progresses, internal or external events (e.g. budget cuts, market downturn, competitor activity) can cause the scope and cost of a project to be reconsidered. Without prioritised requirements, any decisions on cuts in scope are more challenging and may be flawed.
Under specific circumstances, it is possible to avoid prioritisation or it may not prove necessary. This would be the case where the prioritisation is imposed or already decided. For example, a project that is required for regulatory reasons will tend to have well-defined mandatory requirements so all other requirements are not mandatory.
There is an obvious risk if the requirements are imposed by, for example, senior management as there may be poor buy-in if stakeholders representing users are not consulted on priorities which may impact project success.
What Requirements Can Be Prioritised ?
It can be done at several levels including features (e.g. order management), individual capabilities (e.g. use case – credit check customer), constraints (e.g. must manage 60 purchases per second) and business processes (new or changed).
The business analyst
, in conjunction with the project manager and business sponsor (or lead stakeholder), needs to decide at which level(s) it is relevant to prioritise. It is usually sensible to prioritise at all these levels as it is not known either how the scope may need to change and where the costs will be incurred.
Why Is Prioritisation Challenging ?
Stakeholders will ask for everything if there is no disincentive. If they are not responsible for managing cost, there is no incentive to recognise the need for tradeoffs and prioritise one requirement over another.
Stakeholders will have different perspectives – for example, users will be focused on usability and speed. Legal stakeholders will be focused on mitigating legal risks and ensuring compliance. The project sponsor (or equivalent) will be interested in overall business impact, benefit and costs. The customer will focus on their own criteria which don’t take account of commercial realities.
It is no wonder that it is a challenge to balance these different priorities and achieve consensus!
Requirements Prioritisation Techniques For Success
There are many different approaches available. We need to consider the following when choosing an appropriate technique:
- How do we achieve consensus across a group?
- How do we ensure an even spread of priorities? As a rule of thumb, a third should be high, one third medium and one third low;
- How do we accommodate different stakeholders relative importance? For example, the project sponsor is likely to have the final say;
- What approach will best suit the organisation? Formal or informal.
Dot Voting Prioritisation
One technique that can be used for gaining consensus in a group is called ‘dot voting’. There are variations on this theme but the core idea is that each stakeholder has a limited allocation of currency (in this case, sticky dots) that they can use to spend on buying requirements.
The key benefit of this approach is that it doesn’t allow the stakeholder to give every requirement a high priority as there will not be enough dots. There is a gaming element to this as you have to consider how the other stakeholders will vote which could influence how you will spend your money.
This approach should not be considered scientific, not least because results can be unpredictable; it is a means of generating discussion and teasing out people’s priorities. It should be used as an input when gaining consensus on real priorities.
The approach for dot voting is summarised as follows:
- Determine how much currency should be allocated to each individual. It should be limited to ensure that some requirements will receive less currency;
- Explain the approach and steps to the participants;
- Allocate the currency; Use different coloured dots for each participant (as far as possible)
- Post the requirements on the wall on post its or in some manner that allow each requirement to receive votes;
- Ask the participants to place their votes;
- Arrange the votes into three groups to represent high, medium and low;
- Start a discussion about the priorities with any or all of the following:
- Which requirements are low or medium priority which must be delivered? Why are they low priority? (you may agree to move them into the high priority group) Which requirements are high priority that should not be high priority?
- Which requirements are almost high priority? Are we happy with them being medium priority? (you may agree to move them).
- If any requirements change priority, you should give serious consideration whether there should be a requirement you swap to ensure that you maintain the group sizes.
MoSCoW Prioritisation
The MoSCoW rules are employed to help achieve clear prioritisation of requirements. The ‘o’s in the acronym have no meaning. The remaining components of ‘MoSCoW’ as used in this chapter are defined here.
Must have:
These are requirements that are fundamental (they are sometimes also referred to as the ‘minimum usable subset’). Without them, the deliverable will be unworkable and useless.
Should have:
These are important requirements for which there is a work-around in the short term, or where expectations can be managed. They are things that would have normally have been classified as ‘Must haves’ in a less time-constrained situation, but the deliverable will still be useful and usable without them initially.
Could have:
These are requirements that can more easily be left out at this point. They may well be included in this delivery if their inclusion is easy to achieve without jeopardising the delivery of the ‘Must haves’ and ‘Should haves’.
Want to have but won’t have this time round (or won’t get yet):
This refers to those valuable requirements that can wait until later.
This clear definition of terms with precise meanings is significantly better than any prioritisation approach that uses numerical values for priorities, or, even worse, words such as high, medium or low, which do not have a precise meaning outside a specific context.
All of the items in the prioritised requirements list (the MoSCoW list) are due for delivery at some point, although the total delivery may be spread over a number of increments. The MoSCoW rules provide the basis on which decisions can be made regarding the whole project, and during any time boxes included within the project.
Product Backlog Prioritisation
A product backlog is a list of product features and requirements that need to be delivered. It is usually prioritised in order of value, with the most valuable items at the top of the list.
One of the most important things to keep in mind when prioritising the product backlog is the impact that each item on the list will have on the business. Not all product features are created equal, and some will have a much greater impact on the business and customers compared to others. It is important to take this into account when prioritising the product backlog.
The product manage or product owner (and stakeholders) will need to agree on what criteria should be used to determine the value of a product feature. This could be things like how important the feature is to the customer, how much revenue it will generate, or how much it will cost to develop. Once the criteria have been agreed upon, the product backlog items can then be prioritised based on their value.
Over time, items in the backlog will change as priorities change or dependencies emerge. So reviewing the backlog and prioritisation is an ongoing activity as the product evolves.
Prioritisation Approaches
Whilst, we tend to consider techniques to prioritise requirements, sometimes there is a need to generally prioritise business analysis information (arising from work activities and artefacts) and consider a prioritisation process to determine relative importance of items being considered.
Prioritisation can be difficult, but by breaking it down into four distinct approaches as mentioned in the IIBA BABOK Guide, the process can become much simpler.
- Grouping – business analysis information is classified, for example, as “high,” “medium,” or “low” priority.
- Ranking – the most critical pieces of business analysis information are placed toward the top of the list, while the less essential material is located further down.
- Time boxing/Budgeting – business analysis information is based on the allocation of a fixed resource, be it time or money.
- Negotiation – stakeholder agreement on priorities for requirement prioritisation.
Having an approach in mind and considering you’re stakeholders and their opinions will help you determine which type of approach may be suitable for the business analysis information that you’re detailing out and seeking prioritisation.
Conclusion – Prioritising Requirements
In this article, I have described why requirement prioritisation is important, why it tends to be unsuccessful and two approaches to gaining consensus in a group.
All business analysts must understand why is it important to prioritise requirements.and how to prioritise requirements.
It is critical to project success to prioritise requirements, why it can be challenging and describes techniques to help achieve consensus.