Starting last year, we began utilizing the SAFe process for portfolio management and software development planning. The SAFe website provides the following description:
SAFe® is an online, freely revealed knowledge base of proven success patterns for implementing Lean-Agile software and systems development at enterprise scale. It provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team levels.
In this post, we will review the prioritization process and some insights that I’ve found useful in quarterly planning. Especially when you have many teams, different products, lines of business or competing priorities. Whether you use SAFe or not, I hope this will be helpful to you and your teams.
Prioritization Steps
We are currently in the throws of prioritizing features for our 10 development teams to work over the next three months (as we do each quarter). There are a few steps to this process:
- Define features with appropriate high-level details, scope and acceptance criteria.
- Estimate features with high-level estimates.
- Evaluate features based on user/business value, time criticality and risk reduction or opportunity enablement.
- Prioritize features using WSJF (Weighted Shortest Job First) calculation.
Define
We must have some high level details about the features in order to estimate, evaluate and prioritize them. Basic information like a brief but meaningful title, general description of the feature, benefits and acceptance criteria. We DO NOT need user stories and tasks broken out. This is too much detail and is unnecessary at this stage.
Acceptance criteria is the key to defining the most important requirements for the feature and how we know when the feature is complete. These are the key capabilities that will provide the users/business value.
Estimate
Next we provide a quick high level estimate of the feature based on its definition. Typically, a single subject matter expert with thorough knowledge of the system works on the estimate. This could be an architect, team lead or team member. If no single person is qualified to provide this you can assemble a team to discuss as a group.
Regardless of who provides the estimate, the key is to not spend too much time on the estimate. Estimates are wrong 99% of the time so its not worth digging deep in to the finer details. Get the big pieces defined and estimated then aggregate them to get a total estimate for the feature. If there are unknowns that could change the estimate by more than 30% than you should probably get answers to those if you can. If you can’t, just use your best judgement assuming it will be harder or more complicated than you expect and increase the estimate accordingly.
Once estimates are complete, you can quickly review them with a development team to ensure you haven’t missed anything big, if necessary.
When estimating the work, sunk costs/effort should be ignored. It doesn’t matter that you have already worked on some new application/system for months or years. All that matters is the work that is left to complete the features and realize the value. It is better to try to avoid these scenarios and only work on features than can be completed within your timebox but it does happen from time to time.
Evaluate
The business sponsor or major stakeholders of a feature will need to assign value to that feature. There are several types of value:
- Business/User Value – The value provided directly to users or the business. There are many ways to express this. For example, you may use revenue expected from the feature, cost savings expected from the feature or a ranking based on customer importance.
- Risk Reduction/Opportunity Enablement – The value provided (usually indirectly) in the form of risk avoidance or the potential opportunities provided. This value could be expressed as the revenue at risk if a feature is not implemented or how many opportunities a feature provides to dependent products/systems.
- Time Criticality – The effect time has on the value of a feature and when it is delivered. For example, if a particular feature is only valuable to customers in August of each year, time criticality would be low when you evaluate the feature in September but have a very high time criticality if you are evaluating in July.
It is often difficult to relatively rank features against each other when they are for different products, divisions or lines of business. One approach to this issue is assigning value based on its effect on profit. The goal of business is to make a profit. Many business stakeholders lose site of this and are only concerned about fighting for resources to get their work done. When you assign value based on the features effect on profit they can see the larger context and often times will defer to features that will bring the most benefit to the company as a whole. This approach also forces stakeholders to think more deeply about what they are asking for and how it will really effect customers.
WSJF – Weighted Shortest Job First
Once we have estimates and value defined for features we can use the WSJF calculation to rank features so we can prioritize the work that will bring value to the business the most quickly. The WSJF calculation is as follows:
(Business-User Value + RR-OE Value + Time Criticality) / Job Size
Although technically not required, it is common practice to normalize your values with relative ranking using the Fibonacci sequence (1, 2, 3, 5, 8, 13, …). For each value type, you would compare the features against each other and assign a number. The feature(s) with the least amount of value would be assigned a value of 1 and higher value features would be assigned higher Fibonacci numbers.
Notice the job size is a denominator in the calculation. This means it has more weight in the calculation. Features with higher job sizes will be given a lower WSJF score. The reason for this is two fold:
- Deliver Fast – We want to optimize for delivering value to the business as quickly as possible. The sooner a feature is delivered the sooner we can start realizing the value of that feature.
- Avoid Risk – Larger features have a larger surface area of requirements and technical complexities that can be missed. Thus they tend to be even larger than you expect. Estimates for smaller features are less likely to be wrong.
For both of these reasons, you should push the business to break up features in to small deliverables when possible.
Summary
Hopefully this post was helpful. We have found the WSJF process to be VERY valuable. I would encourage you to try it whether you are in a large or small business. In general, we have found it to be more accurate and less time consuming than other priorization methods.
Please share your thought in the comments below to continue the conversation and raise new ideas/concerns.