City tour or beach vacation? Electric automobile or gas-powered? The red shoes or the black ones? Many people have a hard time making decisions, and it’s no different for project stakeholders. This is especially true when it comes to deciding which requirements to implement and with what priority. It’s up to the requirements engineer or business analyst to make sure these decisions get made. Prioritization workshops can be a great way to accomplish this. However, they need to be well prepared. Here you’ll learn some tips and tricks.
What’s prioritization about?
Prioritization determines the importance of requirements and in what order they should be realized. That sounds pretty simple. In practice, however, it’s rarely that easy. It often happens that priorities are determined by the stakeholder with the “loudest voice,” the most influence or the closest relationship with the team or management. Prioritization means determining the relative importance of requirements in comparison with the other requirements in the backlog. Two factors need to be balanced:
- the potential business value the requirement will create, that is, the contribution it will make toward achieving business goals
- the associated risks, hurdles to implementation and resource demands
Why workshops?
Here a workshop is understood to be a meeting where the moderator brings along a set of tools. The moderator utilizes these tools with situational aplomb in order to create consensus and compromise.
So, what tools does a moderator need? The answer is that it depends on the workshop participants. The Business Analysis Body of Knowledge BABOK v3 offers some orientation. It divides prioritization techniques into four approaches:
Selection of prioritization techniques depending on the participants in the workshop (according to BABOK v3)
What’s behind these prioritization techniques?
Grouping
Grouping means sorting requirements according to a specified classification scheme.
The most well-known grouping technique is surely the MoSCoW method, which is often used for release planning. MoSCoW stands for:
- M – Must have (essential, must be implemented)
- S – Should have (should be implemented, provided this is not detrimental to must have requirements)
- C – Could have (can be implemented, as long as this doesn’t negatively affect the implementation of requirements with higher priority)
- W – Won’t have (can’t be implemented now, but intended for later)
Another example of grouping prioritization to sort requirements into Rocks, Pebbles & Sand. This classification scheme is particularly useful for communicating with product managers when prioritizing requirements at a high level of abstraction – i.e. when topics or epics are involved.
- Rocks are heavy-duty requirements that make a difference, create high value, i.e. lead to decisive competitive advantages
- Pebbles are requirements that add something to the product, but don’t create a high value for each and every user/customer
- Sand refers to requirements of minor important that can be dealt with on the side if there’s idle time
Ranking
Grouping is helpful, but it can be problematic. For some stakeholders, nothing is optional. Surely you’ve encountered stakeholders who can’t accept anything less than the immediate fulfillment of all their requirements? When you’re dealing with such stakeholders, the group of high-priority requirements can get too large. If that happens, you need to use your powers of persuasion to get stakeholders to create a ranking of the backlog requirements.
Timeboxing/Budgeting
If the path to the solution is known, you can set priorities by referring to facts. This is similar to the way requirements – i.e. user stories – are planned for sprints using the timeboxing principle. The same thing applies when a project group has a fixed budget and selects requirements for implementation based on available resources.
Negotiating the prioritization
Negotiation is definitely the most difficult approach for the moderator. Here it’s all about creating a consensus. It is therefore essential that – before the workshop begins – you carry out a detailed analysis of the stakeholders, their relationships, motivations and goals.
How can objectiF RPM help you with prioritization?
Requirements engineering is one of objectiF RPM’s strong points. It comes with everything you need to:
- Record and keep track of stakeholders, their relationships and goals using forms and diagrams
- Document and analyze requirements and their relationships, both to other requirements and to stakeholders, goals and potential risks
Regarding the prioritization techniques described here, objectiF RPM provides the following:
- For prioritizing requirements with stakeholders, objectiF RPM offers configurable backlogs. You can sort, group and filter according to useful criteria that give you an easy overview. To get more details, you can open individual requirements and edit them directly in the backlog.
- Backlogs come with a mechanism for ranking requirements. A requirement’s position in the list corresponds to its rank. Requirements can be moved up in rank simply by dragging and dropping.
- One grouping technique is even built in. In the backlog and requirements form, you can prioritize using MoSCoW.
With these features, you can get straight to work in your prioritization workshop. Get a closer look at objectiF RPM and learn more about how it can support you with requirements prioritization by downloading a free trial edition.
The following video in German (please switch on English subtitles) shows how to rank requirements with objectiF RPM:
Source:
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) v3, IIBA® International Institute of Business Analysis™, 2015.