A comprehensive guide for WSJF Agile Prioritization Framework: formula, definition, meaning, score, and its use in prioritization. Start now with a professional template.
Disclaimer: It’s essential to understand that WSJF is not just a formula but part of an extensive workflow framework for an enterprise. The magic happens only when you change your decision-making approach: running collaborative prioritization sessions, setting score expiration, specifying criteria, and explaining and redefining your task descriptions to your teammates. This article aims to provide you with tools to create that prioritization habit and shift your mindset.
WSJF prioritization in a nutshell
WSJF score = (Business Value + Time Criticality + Risk Reduction) / Job Size
- User / Business Value ranks your jobs by their relative importance to the user and potential impact on revenue.
- Time Criticality ranks the jobs by urgency: how the value will decay over time or how many customers we may lose if we linger.
- Risk Reduction and Opportunity Enablement help you highlight jobs that may not bring revenue immediately but benefit the long-run. Some solutions will help you eliminate technical or legal risks and save you money later.
- Job Duration is also called story points, feature points, effort, or relative size. With this estimation, the smaller the number, the better.
- You must evaluate each criterion on a scale: 1 (no impact), 2, 3, 5, 8, 13, 21 (highest impact).
- Run a collaborative prioritization session with a team of five to eleven people each.
- Evaluate tasks before each iteration planning event (sprint).
- Normalize different scores via discussion with teammates.
- Initiatives with ‘21’ and ‘13’ Job Sizes to be cut into smaller projects (backlog refinement).
- Reset evaluation score every five iterations (Program Increment) to reflect the fast-changing environment.
Apply the Ready-To-Go Ducalis Prioritization Template
No need to customize all those criteria, formulas, and scales. Feel free to use them as a boilerplate setting to kick off the meeting.
WSJF stands for Weighted Shortest Job First, a prioritization framework (prioritization model) to prioritize backlogs by calculating the relative Cost of Delay (CoD) and job size (a proxy for the duration). CoD calculates as a sum: User / Business value + Risk Reduction and Opportunity Enablement + Time Criticality. It is a part of the SAFe methodology.
Backlog priorities are continuously updated based on WSJF priority scores. In addition, the framework conveniently and automatically ignores sunk costs, a fundamental principle of Lean economics.
In a flow-based system, continuous task prioritization for updating priorities provides the best economic outcomes for:
- Job sequencing by pushing quick wins forward.
- Balance of the highest financial result while lowering invested resources.
- Regular updating of CoD and Job Sizes to reflect the fast-changing environment.
What is SAFe?
The Scaled Agile Framework® (SAFe®), according to ScaledAgile.com, is a system for implementing Agile, Lean, and DevOps practices at scale. It takes the best ideas from agile product delivery and expands them to the whole enterprise to provide business agility. SAFe is the most popular framework for leading enterprises because it works: it’s trusted, customizable, and sustainable.
It updates constantly and has versions. In 2022 the latest version is 5.1, and SAFe covers seven main areas of enterprise:
- Team and Technical Agility
- Agile Product Delivery
- Enterprise Solution Delivery
- Lean Portfolio Management
- Organization Agility
- Continuous Learning Culture
- +50% faster time-to-market
- +50% defect reduction
- +35% increase in productivity
- +30% happier, more engaged employees
Pretty neat results. Who wouldn’t want that?
In this article, we’ll only focus on its foundation — the WSJF decision-making framework.
How to Calculate WSJF (Weighted Shortest Job First)
The Weighted Shortest Job First (WSJF) framework goal is to help decide what task to choose next to deliver the most value with limited resources by finding a balance between Cost of Delay (CoD) and Job Size in a fast-changing world.
Calculate WSJF Score
Calculate CoD, which defines three types of product development issues you should watch.
Cost of Delay = User-Business Value + Time Criticality + Opportunity Enablement Value
Each criterion should be evaluated with a scale of 1, 2, 3, 5, 8, 13, 21.
Here are the estimation principles:
- WSJF estimation aims to understand the level of uncertainty, not calculate hours or money (which is nearly impossible). That’s why we try to estimate a probability rather than an exact time for accomplishing a particular task. It’s called relative evaluation.
- As the main goal is to deliver value in each iteration, the median of the sequence will be “one iteration.”
- One iteration = two weeks. Our planning baseline. We calculate our story point numbers for a two-week iteration.
- Program Increment (PI) = five iterations (ten weeks). According to SAFe, PI is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. The whole team realizes something large for the product. In other words, the organization releases a big update, after which they should re-evaluate their backlog, think, and discuss priorities once again.
Please keep in mind that it’s only a recommendation, and you are free to customize the approach in any way that is comfortable for your team. Later in that article, we cover how to better understand and customize the criteria precisely for your business needs.
User-Business Value (UBV)
New features and innovations that drive your product forward. For example, enterprises’ security login options will help avoid complaints from large customers, which leads to sales.
User / Business value (UBV) ranks your jobs by their relative importance to the user (Prioritizing Desirability) and potential impact on revenue (Financial Prioritization). At this point, you estimate how effective this solution is on the overall promotion of your North Star Metric. Then, as many factors may influence UBV, start thinking about business impact and increase your confidence that it will all work out.
Answer the questions: What’s a vital product metric you can update? How important is this for the users? What is the impact on the revenue?
User-Business Value Evaluation with Fibonacci Sequence
- 1 point: no user-business value at all; this task is related to something else.
- 2 points: the lowest business impact and confidence.
- 3 points: low business impact and confidence.
- 5 points: moderate business impact, moderate confidence.
- 8 points: high business impact and confidence.
- 13 points: very high business impact and confidence.
- 21 points: the highest business impact and confidence.
Time Criticality (TC)
Evaluate urgency. Initiatives have justified deadlines like new regulations, tax reporting, seasonal promotions, etc.
Time Criticality ranks the jobs by urgency. You estimate how the value will decay over time or how many customers we may lose if we linger.
Our estimation timeframe is from one iteration (two weeks) → to one Program Increment (PI) (ten weeks). Each PI cycle, we run a new re-evaluation session (after score expiration) and decide how the urgency changed.
Answer the questions: How urgent is it for the business? Will users wait or move to another solution? Is there a fixed deadline?
Time Criticality Evaluation with Fibonacci Sequence
- 1 point: not a time-critical task at all.
- 2 points: it can wait till the next estimation cycle (after score expiration every five interactions).
- 3 points: it can wait for four sprints (about eight weeks).
- 5 points: moderate urgency, it can wait for three sprints (about six weeks).
- 8 points: it can wait for two sprints (about four weeks).
- 13 points: it can wait for one sprint (about two weeks).
- 21 points: the highest urgency, you must take that issue to the next sprint.
Risk Reduction | Opportunity Enablement Value (RR | OE)
Tasks to avoid or reduce technological or business risks. Examples include code refactoring, database update, security, or tax audit – something that you must do to ensure the healthy operating of a product.
Risk Reduction and Opportunity Enablement help you highlight jobs that may not bring revenue immediately but benefit the long-run. Some solutions will help you eliminate technical or legal risks and save you money later. Others may open doors for further improvements that will significantly increase the number of potential customers.
Answer the questions: If the task starts with some risk description, how big of an impact will that risk be? What probability?
Risk Reduction Evaluation with Fibonacci Sequence
- 1 point: it doesn’t provide any risk reduction at all.
- 2 points: reduce the likelihood of a lowest risk, lowest severity probability.
- 3 points: reduce the likelihood of a low-risk, low severity probability.
- 5 points: reduce the likelihood of moderate risk moderate severity probability.
- 8 points: reduce the likelihood of a moderate-high risk, high severity probability.
- 13 points: reduce the likelihood of a very high-risk, very high severity probability.
- 21 points: can reduce the risk of a highly impactful event, a disaster that is most likely to happen.
Job Size (Job Duration)
Job Size is the only negative factor and ranks the jobs by the realization complexity. It’s impossible to achieve the highest ROI without considering the costs of person-hours required. Duration is also called story points, feature points, effort, or relative size.
Answer the questions: How long will the implementation take? Are there dependencies that can make it more time-consuming?
Job Size Evaluation with Fibonacci Sequence (story points)
- 1 point: no effort at all is required. We can’t divide by zero, so our Job Size estimation should start from 1.
- 2 points: the estimation baseline. 80% probability that one day is enough to code and one day to test and validate for a two-week iteration.
- 3 points: a task about a quarter of your sprint efforts.
- 5 points: something half of your iteration. 80% probability that the task will take 5 workdays to code and one day to test and validate for a two-week iteration.
- 8 points: 80% probability that a task will be developed and tested within two weeks (one iteration/sprint).
- 13 points: between one and two iterations.
- 21 points: “Buzzlight estimations,” something that takes two sprints or even more (“to infinity and beyond”). From my practical experience working with teams, you will be evaluating lots of ideas that exceed one iteration and should be divided into smaller chunks.
The final formula for calculating the WSJF score is:
Customizing Criterion for Your Team
In the standard Scrum framework, each team’s story point estimating – and the resulting velocity – is a local and independent concern. Here is a kick-off point for your evaluation process. You can apply it from the Ducalis WSJF template and modify the criteria descriptions.
There is no the only right definition for a scale. If you and your team are confused by any term — change it! Ducalis is quite flexible in that regard.
Agile processes’ core is the basic building blocks called iterations or sprints. Each iteration is a standard fixed-length timebox where Agile Teams deliver incremental value.
Iteration Planning Event (Product Increment)
Each iteration should start from a clear list of priorities. Before that planning, you should have an evaluated backlog. Teams may often spend the whole week between development cycles for evaluation, prioritization, and planning. Then, deploy value in short iterations (sprints).
Ducalis can save that whole week for your team via an asynchronous evaluation process. Just set a day of planning, and Ducalis will do the rest. In addition, you can track evaluation progress with the team’s evaluation progress report.
To motivate your teammates to evaluate in time, it’s always great to offer support with encouraging messages. Go to prioritization habit settings and set a rewarding message for teammates who finished their evaluation in time before the upcoming iteration planning meeting.
The Power of Re-Evaluation
Top priorities, urgency, and business values are perishable products. This is because there’s so much input – new customer requests, bugs, technical debts, new regulations, fancy ideas, and much more.
The whole idea of SAFe is to adapt in a new way to a fast-changing world. A company’s environment changes every five iterations (one PI). Therefore, it’s highly recommended to reset evaluation scores.
In a flow-based system, continuously updating priorities provides the best economic outcomes. Job sequencing rather than theoretical, individual job return on investment produces the best result in such a flow context.
A side benefit of backlog re-evaluation is backlog grooming/refinement. While thinking about each backlog item, you will get some ideas on how to merge, update, or remove your task as some information will have become outdated for some reason. From Ducalis.io‘s experience, we draw from 2% to 5% of our backlog items every re-evaluation cycle.
To set up re-evaluation cycles, click on ‘Meeting in # days’ and scroll down to the score expiration section. By default, your team’s evaluation scores will expire after starting the next PI cycle.
By default, the sprint is two weeks long. Customize it in the prioritization habits section.
Pro tip: if your scores expired and didn’t finish the previous PI, you can always restore your scores and extend the prioritization period.
Agile estimation is a team sport. Each agile team comprises five to eleven members. Invite your agile (cross-functional team) to the prioritization process.
When a team estimates product backlog, they don’t know who will work on each task. Therefore, teams will usually determine that during iteration planning (sprint).
This is why the whole agile team evaluates every product backlog item.
The whole team needs to understand the logic behind the story points’ assignment to reach a consistent practice. All team members vote without being influenced by other team members. Outside pressure or insufficient teaming can quickly inflate story points, affecting forecasting.
Sometimes prioritization meetings may be led by the loudest person in the room. This means you may interfere with each other during the evaluation session. Let everybody prioritize at their own pace.
Choose ‘The Right Impact’
We talked about the business impact at the beginning of the article. But what answers will you get if you ask different roles: a simple question “What is the most impactful thing we should do next?” For example, I bet a developer will tell you “faster database,” a sales-person will say “a feature request for the biggest customer,” and a product manager will ask “new retention message,” etc.
It’s nearly impossible to compare which is more impactful. However, that’s a good thing to consider for every agile team and precisely what Ducalis can handle for you.
Collect Different Opinions
Prioritization frameworks are great for keeping emotion and politics out of a decision so that you can rely on facts instead. However, when you prioritize alone, you are still biased. Borrow the poker planning technique for prioritization. With Ducalis, invite each team member to prioritization.
Open criteria settings and invite teammates to your shared evaluation team.
This will provide each teammate with their evaluation list for independence estimation.
Specify Criteria for Each Role
Let’s say you need to develop a new feature for your website. You have at least three roles – UX designer, front-end, and back-end – all have a different Job Size for that feature. UX needs a Job Size of 3 days, front-end needs one day, and back-end needs five days. What is the Job Size for the total project?
The problem is not about calculation, but that your team should find a timeslot to discuss it. In a remote-first world, that means one more zoom call and discussion. More work around work.
Ducalis can handle that for you with an asynchronous prioritization approach.
Open criterion settings, choose the board teams tab and create different teams/roles.
Now you can assign a specific criterion to a particular role. So, for example, the back-end and front-end teams have their evaluation criteria.
After that, each team member will evaluate backlog items with their criteria set, which they are responsible for estimating.
When Everyone Participates, It Increases Buy-In
The side effect of collaborative prioritization is that teammates better understand what’s going on with the product. We know what challenges, requests, and ideas we have and why some are more important than others. It increases morale and team involvement.
A bit of normalization occurs through regular practice, helping to ensure that everyone on the team makes the same assumptions behind sizing. For example, if one person sizes an item at a “2”, but another person sizes it as an “8,” given they share similar abilities, they have interpreted the requirement differently or approached it from different directions. When this happens, the Developers collaborate with the Product Owner to clarify assumptions and agree on a size. (This does not need to be a consensus — people can agree to disagree.)
While a team is learning what the Fibonacci scale means to them, with their unique set of skills, tenure, and domain knowledge, it is helpful to compare new requests to completed work with shared similarities. For example, when a new item is assigned a story point value of 5, compare it to similar things with the same size and adjust the points accordingly.
With Ducalis, you can quickly check the team alignment report to get a heat map of disagreements. This is another tool for asynchronous prioritization instead of running a poker planning session, where the majority of estimations won’t need any discussion at all.
Divide Into Smaller Chunks
One of the biggest misunderstandings about WSJF is that it may focus your team only on easy tasks (low-hanging fruits). Instead, the smaller the Job Size for a particular task, the higher the priority score and the higher the task will be ranked.
Use a matrix for slicing your backlog into pieces and deciding what to do with your tasks.
Through the practice of refining – breaking work into smaller, more valuable chunks – the Developers continue to gain insight. As each request becomes smaller and more is known, they continually revisit the size. Therefore, it’s good to provide three touchpoints to help the team with the emerging design, development, and dependencies.
- Don’t try to be too precisive. If you have a task for one hour, don’t be afraid to set a baseline for one day. It will all be compensated and balanced in the long run.
- Roundup estimations to the next value.
- However, the final decision remains with the product professional accountable for sequencing the items in the backlog in question. Factors such as regulatory deadlines, legacy system fragility, or building a foundation for future features may be challenging to put into financial terms but still need to be considered.