Prioritisation is often carried out by negotiation between multiple stakeholders and the Product Owner. The negotiation occurs at different times usually between one stakeholder and the Product Owner. This causes communication overhead, confusion and triggers reprioritisation.
 |
| Prioritisation by negotiation, as often occurs |
An appropriate Prioritisation Framework will build consensus for the prioritisation decisions, hence avoiding the above mentioned issues. Here the Product Owner uses the Prioritisation Framework and associated meetings as a way to facilitate the prioritisation process and ensure that consensus is reached with the majority of stakeholders present.
 |
| How a Prioritisation Framework can streamline the prioritisation process |
Scope of a framework
For items that need rapid prioritisation, such as small ongoing tasks like bugs, enhancements and tweaks to existing features; I recommend that they are handled outside of the prioritisation framework. The primary reason for this is that often those work items can be fixed faster than the time it takes to score, discuss and evaluate and analyze.Considerations for selecting an appropriate framework
- The framework should be light weight & easily understandable. This will greatly assist the uptake, buy in and will reduce communication costs.
- The framework should allow for comparison of different types of work (e.g. Contractual vs. acquisition vs. vs. enablers for future work). None of the suggested approaches involve calculating the value of the change in $. Those calculations are complex at best, and impossible in the worst case. Instead the suggested frameworks focus on Relative Estimation over Absolute Estimation.
- The framework should consider the rough size of each piece of work. This allows for small, medium value work items to compete with large, high value pieces of work. The end result being that we achieve a balance of quick wins and strategic goals.
- The framework should provide a simple way to adapt the prioritisation decisions to your changing strategic needs.
- You need all stakeholders to buy into the framework, and agree that it will drive prioritisation. Once this is done, the framework will allow for fast decisions. If some stakeholders disagree with the framework, they will undermine the decisions that come from it. Lack of adherence, will slow down the process and cause confusion.
- All of the frameworks that I am about to suggest rely on gathering groups of decision makers together, so that the decision making process is transparent and fast. Gathering all of the appropriate decision makers may be a tough ask in some situations.
Possible Framework - Value & Size Comparison
Value is determined via Product Owner group applying absolute estimation highest is more valuable. Size is determined via Delivery Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. The changes are then mapped onto the matrix below, which leads to discussions on priority.
Cons
- Subjective value measurement is open to emotion / rank over taking the real value.
- Value is a very simplistic representation, which makes it difficult to compare changes of differing types. i.e. Customer Retention vs. Technology Enabler.
Pros
- Simple, easy to understand and communicate.
- Uses group consensus for both Value and Size, which builds acceptance of the decisions.
Possible Framework - Money Voting
A simplistic voting approach. It subconsciously makes the participant consider the relative real world value of each change.
Each stakeholder is given a sum of imaginary money (say $100) which they are asked to distribute amongst the items on the backlog. Priority is then judged by the sum raised by each item.
Cons
- Subjective value measurement is open to emotion / rank over taking the real value.
- If ‘spending’ is done in the open, whoever goes first can set a precedent and whoever goes last has more power to influence the final outcome.
- Can be time consuming if done in private, as different stakeholders will respond at different times. They may also delay waiting to see how over stakeholders are spending their money.
- Does not include size; however it would be simple enough to divide the Total Score by Relative Size.
Pros
- Simple, easy to understand and communicate.
- Quick if done in the open, but has the Cons related to influence.
Possible Framework - Weighted Shorted Job First (WSJF) from SAFe
Documented in Scaled Agile Framework (SAFe), based on work in Don Reinertsen’s book ‘The Principles of Product Development Flow’ as explained here
Higher WSJF indicates higher priority.
User, Business Value, Time Criticality, Risk Reduction & Opportunity Enablement are all determined via Product Owner group applying Relative Estimation, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable.
The value of User, Business Value, Time Criticality, Risk Reduction & Opportunity Enablement are estimated by the Product Owner group in turn. To do this they select the work item with the lowest User/Business Value and assign it 1. The other work items are estimated by applying Relative Estimation, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable. The Product Owner group then moves onto Time Criticality and repeats the process. Finally they do it for Risk Reduction /Opportunity Enablement.
Size is determined via Team Leader / Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. This is a stand in for duration. WSJF really calls for duration of the job not size but size is usually a very good substitute.
Cons
- Cost of Delay is difficult to explain
- Assumes that there is equal importance between the three key criterion (User/Business Value, Time Criticality & Risk Reduction/Opportunity Enablement. This may not match the needs of the business.
Pros
- Financially sound approach (minimising cost of delay).
- Purely relative estimation approach, each round of estimation is only using the current projects to help determine priority.
- Uses group consensus for both Value and Size, which builds acceptance of the decisions.
- Removes some emotion from prioritisation process.
- Allows for comparison of different types of changes.
Possible Framework - Prioritisation Matrix
This comes from the model documented by University of Wisconsin-Madison
Higher score indicates higher priority.
An agreed set of Criteria (with scoring notes) are selected for use in the framework. Each Criterion is given a weight relative to the other criteria. These criterion and weights do not change.
Criteria Scores are determined via Product Owner group absolutely rating each change on the scale of 0 to 9, using the Scoring Values for guidance. 9 is the highest value. These scores are then used to calculate the total score.
It is best explained with an example.
Cons
- Does not include size; however it would be simple enough to divide the Total Score by Relative Size.
- It could be difficult to gain acceptance of the criteria scoring system and weightings.
- Uses rating (matching up to the scoring values) instead of Relative estimation.
Pros
- Customisable criterion, enable the prioritisation matrix to match the business needs.
- Uses group consensus for Value, which builds acceptance of the decisions.
- Removes some emotion from prioritisation process.
- Allows for comparison of different types of changes.
- A key benefit of this is that everyone understands the main company goals and is motivated to come up with features that push the scoring up.
Possible Framework – Customised WSJF Framework
A combination of WSJF with a customised Prioritisation Matrix. This is what I would usually recommend.
Higher Score indicates higher priority.
Similarly to WSJF the Product Owner group estimates each criterion in isolation; however the list of criterion is an agreed list of criterion similar to the Prioritisation Matrix. They start with the first criterion, select the work item with the lowest value and assign it 1. The other work items are then estimated relative to the first item for the current criterion, on this scale (1, 2, 3, 5, 8, 13, 20), higher is more valuable. The Product Owner group then moves on the next criterion and repeats the process, until all criterions have been completed.
Size is determined via Team Leader / Team Representative group applying Relative Estimation on the Planning Poker scale, larger is bigger Size/Cost. This is a stand in for duration. WSJF really calls for duration of the job not size but size is usually a very good substitute.
To keep the process quick I recommend that a maximum of 5 criteria are selected. I would start with:
- Constraints – Time constraints, Regulatory constraints.
- Customer Joy – delighters, differentiators.
- Revenue – conversion rates, income, projected income.
- Risk Reduction / Opportunity Enablement (RR OE) – Increase redundancy, reduce technical debt.
Other suggested criteria to consider
- Strategic Alignment – matching the company’s strategy goals.
- User Impact – high number of user or small number of key users impacted.
Cons
- Cost of Delay is difficult to explain
- It could be difficult to gain acceptance of the criteria scoring system and weightings.
Pros
- Financially sound approach (minimising cost of delay).
- Purely relative estimation approach, each round of estimation is only using the current projects to help determine priority.
- Removes some emotion from prioritisation process.
- Allows for comparison of different types of changes.
- Customisable criterion, enable the prioritisation matrix to match the business needs.
- Uses group consensus for criterion, which builds acceptance of the decisions.
- A key benefit of this is that everyone understands the main company goals and is motivated to come up with features that push the scoring up.
An example again helps to explain it.
