By Nick Butler
Tags: Agile , Development
Find out why prioritisation is vital to Agile development and get practical and powerful Agile prioritisation tools to help you reduce software development risk.
Action expresses priorities.
Mahatma Gandhi
In Agile, prioritisation is one of four key approaches for managing risk, along with increasing transparency, reducing batch size and limiting work in progress. Each approach is especially effective for reducing one or more of the most common software development risks — risks around quality, time, cost and value.
Together these risks and approaches can be summarised in this Agile software development risk management model.
Get your complete guide to
Project risk management with Agile
As the model shows, prioritisation is an important approach for managing and mitigating the risks around cost and value in our projects. Rigorously prioritising work reduces the risk of delivering software of low value while also ensuring that costs are controlled by only working on what is important to our organisation and customers.
Working on features that have little to no value to users is a problem common to many software development projects. Value to the organisation is delayed as a lack of prioritisation leads to long development times and large slow release cycles while we wait for something of value to be delivered.
Working on low-value features also reduces team morale and productivity.
In Agile software development, prioritisation is the process of forced ranking of features (or equivalent) to ensure that the work with the most value is completed first. Prioritisation happens continuously throughout a project and enables changing priorities and new information to influence the development of products.
It is important that there is a robust methodology for prioritisation. Different projects work with different methods to determine value. In this post, we will look at ‘weighted shortest job first’ (WSJF) which gives us a robust, economic framework for making decisions. WSJF works well for all organisations but particularly for larger ones as it takes into account not only the value of the feature but the cost of delay.
Not delivering value is a key software development risk. We can ship software sooner with rigorous and continuous prioritisation. Shipping sooner delivers value to our customers and our organisation earlier, giving us greater feedback on the direction we have taken and enabling us to measure our return on investment (ROI).
“In the 2002 Standish Group report, it was observed that mismatching customer satisfaction with the functionality of delivered software is still one of the main reasons that many software projects fail to achieve their stated objectives.”
The Science and Practice of Software Release Planning, Günther Ruhe, Moshood Omolade Saliu
In the chart above we can see that 45% of enterprise software is never used. Nearly half of the features are of no value to users. The cost to our organisations of these never-used features is incredibly high. The cost, time and resource required for software development are greatly increased, along with the complexity of the product.
Increased complexity increases the cost to our organisations of maintaining the code base, adding new features and supporting existing features. Users require more training and support as they seek to navigate overly complex lists of features to get to the features they truly use. Greater complexity also makes it harder to keep your system secure. You can learn more in our guide to managing security in Agile software development.
Working on features that will never be used limits the opportunity to work on features that are of actual value to users and reduces the overall value of our software.
In summary, lack of prioritisation causes:
Fill in the table below to see how your project or organisation is doing with prioritisation.
Download your printable Prioritisation evaluation checklist (PDF).
| Practice | Yes/No |
| All features are prioritised | |
| Features are prioritised based on business value | |
| We have a shared understanding of what business value means for each of our projects | |
| The features still to be worked on are re-prioritised regularly (at least monthly) | |
| We can introduce new work into the backlog at any time | |
| Prioritisation is collaborative and transparent | |
| Everyone who should be involved in prioritisation is | |
| A prioritised backlog is visible to the team at all times | |
| When new information (technological, process or market) becomes available work is re-prioritised as necessary |
Add up one point for every question to which you answered ‘yes’.
0-2 points: Adopting a more rigorous approach to prioritisation will have a dramatic effect on the value delivered in your projects or … concentrate on your golf.
3-6 points: You are already doing a great deal to ensure prioritisation is happening and is valuable. There are probably one or two practices that will sharpen your prioritisation.
7-9 points: You are getting the most from prioritisation already – nice work!
At its simplest, we can rearrange the queue of work collaboratively with stakeholders to determine priority. This works well for smaller projects where stakeholders have a clear view of the customer and the organisation’s need.
With smaller Scrum projects we will often have the product owner (or product ownership team) meet with the team to prioritise the work.
The key is not to try and prioritise the whole backlog in this initial session. Backlogs are naturally loosely prioritised because they are developed with the most urgent and high-value features arising first in the product discovery phase. By examining the minimum viable product (MVP) or the work of the first two to three sprints, we have a good set of stories to prioritise.
During the prioritisation session, the team sizes the stories so that the product owner has an understanding of the effort involved in the work.
In practice, prioritisation is achieved by printing all the stories in the backlog and getting the product owner to move them around on a tabletop or arrange story cards on a wall and sort them into priority order.
This list becomes the prioritised backlog. Typically the product owner would re-prioritise the backlog before the start of each sprint so that the team is always working on the highest value features.
A common and basic tool for prioritisation is determining the effort involved for each feature and the (potential return) value. The highest priority is identified as the work with the highest relative ROI, where relative ROI = value/cost.
However, this process misses a key lean product development principle of sequencing work: understanding and factoring in the cost of delay.
In the Scaled Agile Framework (SAFe), Dean Leffingwell suggests that the cost of delay is “an aggregation of three attributes of a feature, each of which can be estimated fairly readily when compared to other features. They are user value, time value, and risk reduction value.”
Don Reinertsen encourages us to quantify the cost of delay and use it to help prioritise the queue of work.
Cost of Delay is the time criticality of the work. If a feature’s value decreases greatly over time or after a specific time it has a high Cost of Delay. For example, if a feature is needed by a certain date to meet a statutory requirement, otherwise incurring fines or sanctions, it would have a high cost of delay. If a feature would have essentially the same value no matter when it was delivered it would have a low cost of delay.
In Reinertsen’s Principles of Product Development Flow, he proposes three models:
1. Shortest job first
If two features have the same cost of delay, do the shortest job first.
2. Highest delay cost first
If two features have the same effort, do the feature with the highest cost of delay first.
3. Weighted shortest job first
When two features have different efforts and costs of delay, then do the weighted shortest job first (WSJF = cost of delay/effort).
Quantifying WSJF can often be difficult, and we need to ensure we don’t over-invest in creating these estimates.
Often the difficulty with estimation lies in wanting a high level of precision leading to extended analysis
Estimates are just that, an estimation. They are not a precise and accurate value. As we learn more about the value and effort involved in a feature we take the opportunity to re-estimate and re-prioritise.
To avoid over-investing in these estimates we can use many of the same tools that teams use to estimate effort. Teams often use tools like ‘planning poker’ and ‘bucket estimation’ to estimate the effort required for features.
These tools work just as effectively to estimate user value, time, value and risk reduction value.
The human mind is much more adept at estimating relative differences than absolute values. For instance, we will be more accurate at estimating the size of a building if we estimate one building relative to another than if we estimate the height in metres.
With relative estimation, we can inspect the output of the team against the estimation to determine future throughput. For example, if a team regularly completes 24-32 story points (an arbitrary relative estimate) per 10 day sprint, we can estimate with reasonable certainty that an eight point story will take two to three days to complete.
Taken from the work of Don Reinertsen, Weighted Shortest Job First gives us a robust model for determining the priority of work based on sound economics.
In Dean Leffingwell’s Scaled Agile Framework (SAFe) it is suggested that Cost of Delay be “an aggregation of three attributes of a feature, each of which can be estimated fairly readily, when compared to other features. They are user value, time value, and risk reduction value.”
Therefore to determine the priority we use the following equation:
BV: User|Business Value
TC: Time Criticality
RR|OE: Risk Reduction|Opportunity Enhancement Value
You’ll found a good overview of WSJF and how it can be applied here.
And here are some more prioritisation tools and tips for Agile projects.
When we prioritise our work, we focus on the highest value work. By focusing on the highest value work we can often produce something much smaller than the full product that is still of value to our customers. This is the minimum viable product (MVP). By getting to the MVP as early as possible we have a product that can be released to customers. Now that our software is in our customers’ hands, we can get their feedback and study how they are using our software. This feedback can be used to estimate the value of future features.
By getting the product to market faster, we can also look at the long tail of the product and set a kill switch. When the value of the features does not justify the effort and nothing of higher value exists to work on, we know that we should stop the project or work with customers to find higher value features to add. We no longer have to finish all the features just because we thought we needed them much earlier in the project.
If we apply the Pareto Principle (80/20 rule), 80% of the value in a product lies in 20% of the features. If an organisation prioritises the 20% of features that will have the greatest impact, the risk of producing a product that does not offer value to its customers is greatly reduced.
Additionally, project costs are controlled by only working on what is important to our organisation and customers. The risk that the project will consume all available resource and still not be in a complete state is diminished.
Robust Agile prioritisation provides opportunities to learn more about the value our software contains and the true cost of delivering that value. We can deliver more valuable software more quickly.
If there is one thing to focus on it is quantifying the cost of delay. This is an essential component of the prioritisation equation and will ensure that you start to see the benefits of prioritisation and Agile quickly.
It is important to avoid over-investing in creating estimates. When new information is available features should be re-estimated and re-prioritised.
Ultimately focusing on prioritisation helps to ensure that we deliver the highest value most quickly. This reduces the risk of running out of resource before having a product of value to take to market.
| Guidance | Case studies & resources |
|---|---|
| Introduction to project risk management with Agile | Agile risk management checklist — check and tune your practice |
| Effective prioritisation | |
| Reduce software development risk with Agile prioritisation | Reducing risk with Agile prioritisation: IntuitionHQ case study |
| Increasing transparency | |
| How Agile transparency reduces project risk | Risk transparency: Smells, Meteors & Upgrades Board case study |
| Limiting work in progress | |
| Manage project risk by limiting work in progress | Reducing WIP to limit risk: Blocked stories case study |
| Reducing batch size | |
| How to reduce batch size in Agile software development | Reducing batch size to manage risk: Story splitting case study |
