How to Decide What to Build Next: A Practical Guide to WSJF
Most teams have more ideas than capacity. WSJF is a simple way to figure out which ones to do first -- and why. This post explains how it works, with real examples.
- WSJF = Cost of Delay / Job Size. Highest score gets built first.
- Cost of Delay has three parts: business value, time sensitivity, and risk reduction.
- The real value is the conversation it forces, not the formula itself.
- Unsexy work (compliance, infra) often scores highest -- and that is the point.
The Prioritization Problem
I have sat in too many planning meetings where the outcome was decided before anyone opened a spreadsheet. The VP of Sales wants the CRM integration because a whale prospect asked for it. The head of engineering wants to pay down tech debt because the build pipeline is slow. The CEO read a LinkedIn post about AI and wants “something with AI” on the roadmap.
Everyone has valid reasons. No one has a shared way to compare them. So the most senior person in the room picks, or the most persistent person wears everyone else down, or worse — the team tries to do everything at once and finishes nothing well.
Key Insight
This is not a process failure. It is the absence of a shared language for talking about trade-offs. WSJF gives you that language.
What is WSJF?
Weighted Shortest Job First is a prioritization method from the Scaled Agile Framework. The name is a mouthful, but the idea is straightforward. For each project competing for your team’s time, you ask two things:
- How much does it cost us to wait? (this is called the “Cost of Delay”)
- How big is the work? (the effort to get it done)
Then you divide the first by the second:
WSJF = Cost of DelayJob Size
Highest score = build it first
The project with the highest score gets done first. That is the entire method.
Think of it like an emergency room. A patient who is critically ill and can be treated quickly goes ahead of a patient with a minor issue requiring a full day of tests. WSJF applies the same logic to your backlog: high urgency plus small effort means “do this now.”
You do not need to adopt SAFe or any particular methodology to use WSJF. It works with Scrum, Kanban, or no formal process at all. It is just arithmetic and honest conversation.
Cost of Delay: The Hard Part
The formula is simple, but the numerator — Cost of Delay — is where the real thinking happens. It is the answer to: “For every month we don’t do this, what are we losing?”
In SAFe, Cost of Delay is broken into three components. I find this breakdown genuinely useful because it forces you to think about value from different angles, not just the obvious ones.
Business Value
This is the most intuitive piece. If we shipped this tomorrow, how much new revenue would it bring in, or how much cost would it eliminate, per month?
For a new feature, it might be projected new subscriptions. For an internal tool, it might be the salary cost of the manual work it replaces. Not every project has a clean dollar figure here, and that is fine — a relative estimate (say, on a 1-to-10 scale) works too, as long as you score everything the same way.
Time Sensitivity
Some projects have a window. Miss it and the value drops sharply or disappears entirely. A regulatory deadline, a competitor about to launch something similar, a seasonal sales event, a contract renewal date — these all create time pressure that makes delay disproportionately expensive.
Projects with no particular deadline score low here. Projects tied to a hard date score high. This component is what separates “important” from “urgent.”
Risk Reduction / Opportunity Enablement
This one gets overlooked most often, but it is arguably the most strategic. Does this project reduce a meaningful risk? Does it unlock future work that is even more valuable?
A security audit might not generate revenue directly, but it might be the prerequisite for landing enterprise contracts. A database migration might not be exciting, but it might be the only thing standing between you and a catastrophic outage. These projects rarely win popularity contests, but they often have the highest real cost of delay.
Putting it together
Cost of Delay = Business Value + Time Sensitivity + Risk / OE
Score each component, then add them up. The sum is the total monthly “pain” of not doing this project.
Real-World Examples
The framework makes more sense with concrete situations. Here are a few I have seen (or variations of them) at real companies.
The compliance deadline that nobody wanted to prioritize
A fintech startup I worked with had a GDPR-like regulation coming into effect in 8 months. The penalty for non-compliance was roughly EUR 100,000. The engineering team estimated it would take about 6 weeks of focused work.
Nobody wanted to do it. It was not a “feature.” It did not show up in customer requests. The product team kept pushing it to the next quarter.
When we ran the numbers through WSJF, the picture changed. The time sensitivity alone was about EUR 12,500/month (the penalty spread over the remaining runway). Add in the risk of reputational damage and the inability to sign contracts with regulated clients, and the Cost of Delay was over EUR 20,000/month. The job was small. It shot to the top of the list.
Lesson: Unsexy work often has the highest cost of delay. WSJF makes that visible.
The big bet that could wait
At a B2B SaaS company, the CEO was pushing hard for an AI-powered analytics feature. The market was buzzing about AI, investors were asking about it, and competitors had started showing demos.
It was genuinely valuable — projected to add $15K-20K/month in upsell revenue. But the estimated effort was massive: 4-5 months of a full squad. And when we honestly evaluated the time sensitivity, it was low. The competitor demos were vaporware. There was no hard deadline. The market window was measured in years, not months.
Meanwhile, a much smaller project — building an integration with a popular CRM — had a concrete opportunity: three signed LOIs worth $8K/month each, contingent on the integration being live by Q2. Two weeks of work.
Lesson: The AI feature was more valuable in absolute terms, but the CRM integration was a far better use of the next two weeks. WSJF made the choice obvious.
The infrastructure project that kept getting deferred
An e-commerce platform was running on a database that had been “fine” for three years. The engineering team had been asking to migrate to a newer system for over a year. Leadership kept saying “next quarter” because there was always a revenue-generating feature to build instead.
Then they did an honest risk assessment. The old database had a non-trivial probability (the team estimated 15-20%) of a major failure in the next 12 months. A failure during peak season could mean $500K+ in lost orders and recovery costs.
Expected risk cost: ($500K x 15%) / 12 = roughly $6,250/month. Add the opportunity enablement — the new database would cut query times in half, directly improving conversion rates — and the total Cost of Delay was around $12,000/month. The migration was estimated at 8 weeks.
It was not the highest-scored item on their list, but it was no longer “something we will get to eventually.” It had a concrete, defensible position in the queue.
Worked Case Study: Three Projects, One Team
Let me walk through a complete example. Imagine you are running product at a project management SaaS company called SyncUp. Your team has capacity for one major initiative at a time. Three projects are on the table:
AI-powered task summaries
Auto-summarize tasks using LLMs. High customer demand, good for marketing. No specific deadline.
SOC 2 compliance
Two enterprise deals ($25K/mo combined ARR) blocked until certified. One prospect decides in 4 months.
Dashboard UI refresh
Dashboard looks dated. Some churn mentions it. No hard deadline, no strategic unlock.
| Project | Cost of Delay | Job Size | WSJF |
|---|---|---|---|
| A: AI summaries | $17,000/mo | 1,200 hrs | 14.2 |
| B: SOC 2 compliance | $30,000/mo | 800 hrs | 37.5 |
| C: Dashboard refresh | $4,000/mo | 400 hrs | 10.0 |
SOC 2 wins by a wide margin, even though it generates zero direct revenue and nobody on the team is excited about it. The reason is clear once you see the numbers: every month without SOC 2, SyncUp is leaving $30K/month in enterprise revenue on the table — and the work is smaller than both alternatives.
The AI feature ranks second. It is the most “exciting” project, but it is also the largest effort with no time pressure. It can wait a quarter without any loss in value.
The dashboard refresh ranks last. It has real value (reducing churn), but with no urgency and no strategic unlock, it can wait until the higher-impact work is done.
Cost of Delay breakdown
WSJF scores
Running a WSJF Session
If you want to try this with your own team, here is how I have seen it work best.
Get the right people in the room
You need someone who understands the business impact (product, sales, or a business lead), someone who can estimate effort honestly (engineering lead), and ideally someone who can speak to risk (security, ops, or a technical architect). Three to five people is ideal. More than that and the meeting becomes a debate club.
List 3-7 initiatives
More than that and the exercise becomes unwieldy. These should be genuinely competing for the same team’s capacity. Do not mix a backend infrastructure project with a marketing campaign unless the same people would work on both.
Score each Cost of Delay component
You have two options here:
Dollar values
If you have reasonable estimates for revenue impact, cost savings, or risk exposure, use them. They make the conversation concrete.
Relative scales
Use a Fibonacci-like scale (1, 2, 3, 5, 8, 13). Score each component relative to the other initiatives. Works surprisingly well because WSJF only needs relative ranking.
Either way, score the three components separately, then add them up for total Cost of Delay. Scoring them separately forces you to think about why something is costly to delay, not just whether it is.
Estimate job size
Use whatever unit your team already uses — story points, person-weeks, t-shirt sizes mapped to numbers. The only rule is consistency: every project on the list must use the same scale. If you are unsure, err on the side of “bigger than you think.”
Divide and rank
Cost of Delay / Job Size for each project. Sort by score, highest first. That is your priority order.
Discuss the results
This is the most important step. The numbers are a starting point, not a verdict. If the ranking surprises anyone, that is a feature, not a bug — it means you are surfacing assumptions that were previously hidden. Talk through the surprises. Adjust scores if the conversation reveals information that was missing. Then commit to the sequence.
A well-run WSJF session takes 30-60 minutes. If it is going longer, you probably have too many initiatives on the table or the wrong people in the room.
Where It Goes Wrong
WSJF is not complicated, but I have seen a few recurring mistakes that undermine it.
Treating the score as gospel
WSJF is a decision-support tool, not a decision-making tool. If the CEO decides to override the ranking for a strategic bet that does not score well — say, entering a new market — that is a legitimate leadership call. The value of WSJF is that it makes the override visible and deliberate rather than accidental.
Agonizing over exact numbers
I have seen teams spend 45 minutes debating whether a project’s business value is $12,000/month or $14,000/month. It does not matter. WSJF is about relative order, not decimal precision. If two projects score within 20% of each other, they are effectively tied — pick either one and move on.
Scoring once and never revisiting
A WSJF score is a snapshot. A competitor launch, a change in regulation, a key employee leaving, a shift in company strategy — any of these can change the Cost of Delay. Re-run the exercise every quarter, or whenever something significant changes.
Underestimating job size
Teams are systematically optimistic about how long things take. If you consistently find that your actual delivery takes 1.5-2x what you estimated, apply that multiplier before you calculate WSJF, not after. Otherwise you are biasing toward large projects that seem smaller than they are.
Comparing across different teams or domains
WSJF works best when you are comparing projects that compete for the same resources. Comparing a mobile app feature against a data pipeline migration does not make sense unless the same people would build both. Use separate WSJF exercises for separate teams.
Ignoring the 'Risk Reduction' component
This is the one that most teams skip or score as zero across the board. It is also the one that, when taken seriously, most often changes the outcome. Infrastructure work, security improvements, compliance, and platform investments all live here. If you zero them out, you are systematically deprioritizing work that prevents future crises.
Closing Thoughts
WSJF is not a silver bullet. It will not resolve genuine strategic disagreements, and it will not fix a team that cannot estimate effort. What it does is provide a structured way to ask the right question: “Given our limited capacity, what is the most economically responsible thing to work on next?”
The real value is not the formula. It is the conversation the formula forces. When a room full of people with different priorities has to assign actual numbers to business value, time sensitivity, and risk, they end up building a shared understanding of what matters and why. That shared understanding is worth more than the ranking it produces.
Pick three projects your team is currently debating. Spend 30 minutes scoring them. See if the result matches your intuition — and if it does not, figure out why. That gap between your gut and the numbers is where the most useful conversations happen.
Further reading