The math behind choosing which 'urgent' thing to tackle next
- Tamara Copple
- Sep 29
- 5 min read
Updated: Oct 13
It is easy for backlogs to get out of control, especially when there is a backlog of technical debt stacked on top of new work, or when executive leadership is struggling to set their own priorities.
My company spent five years on an initiative to transition from our antiquated customer relationship management system to Microsoft Dynamics. We rejected the Must / Should / Could / Won’t (MSCW) method immediately because every proposed feature proved essential.
Next, we focused on determining priority by the number of impacted end-users, viability of interim manual workarounds, and time to market. It was more objective, but not enough to cover some nuances. For example:
What if there are few stakeholders impacted, but they were major clients sensitive to their customer service level? An error with this group could cost us a multi-million dollar opportunity with a client the company had been cultivating for years.
What if the manual workaround the team identified has to be done hundreds of times per day, and is costing overtime, low morale, and normal customers notice a reduction in responsiveness?
This system worked for longer, but by the end of the five years we had already postponed everything that we could and overused the goodwill of our stakeholders by making them use unsustainable workarounds. We had finally caught up to the mountain of proverbial cans we kicked down the road, and we had returned to a position where every proposed item was urgent.
I needed a better way to decide what to prioritize. I needed to defend that choice to the executive leadership. Weighted shortest job first, or WSJF for short, became my silver bullet.
Cost of Delay as an objective way to determine priority
First, it’s a mouthful to pronounce, so I just refer to it as “wizjif.”
People also call WSJIF the Cost of Delay. This prioritization method from Lean frameworks, helps my business stakeholders and me make informed decisions based on value, urgency, and effort.
Business value is a value statement about how directly, or how well, the proposed work aligns to a strategic business objective. The more direct and bright the line drawn between the outcome of the proposal and achieving an organization goal, the higher its value should be.
Time criticality estimates what it will cost not to implement a solution or to postpone it in favor of other priorities. We would prioritize a proposal with a hard deadline over an initiative with an urgent but flexible deadline.
Risk reduction / opportunity enablement (RROE) compels the stakeholder to articulate how the work helps them achieve a strategic business goal or realize efficiencies. This allows us to compare a project introducing operational efficiencies with a revenue-generating proposal.
Effort (or Job size) refers to the size or complexity of the work required to resolve the situation. That doesn’t just mean developers writing code, by the way. Developing a new business process, training, and effort to implement the initiative also count as “effort.”
The business assigns a Fibonacci number to each value. The product owner or the person closest to the group that will build the solution should be the one to estimate the effort.
The mathematical formula prioritizes the highest-value work with the lowest amount of effort. Whether you prefer to use the idiom “low-hanging fruit” or “biggest bang for the buck,” it helps you describe the most cost-effective priority.
Why Fibonacci Numbers?
I used the Fibonacci values from 0 to 21 because our technical team uses Scrum. The Fibonacci sequence is familiar to them. However, I use it differently than they do in planning poker games. The textbook way for developers to use Fibonacci is to assign relative complexity without false precision. For example, a value of 5 is more complex than a 3, and a value of 13 or 21 is work that needs further refinement before the developer team accepts it.
For the business user, however, a wider range (like 0–21) helps capture nuances. Two priorities are both “urgent,” but one is just a little more urgent than the other, even though both may have the same business and opportunity value. A 3 versus a 5 allows for wiggle room.
While the number zero isn't technically on the Fibonacci sequence, I use it to create bands of relative priority.
My version of the WSJF Matrix
The full matrix I developed is best seen in an Excel format, and uses examples relevant to my team's business context at the time, to help my stakeholders decide what value to give each variable.
This matrix helps stakeholders answer questions like:
Is there a manual workaround, and how painful is it?
Will this unlock something valuable, like scale operations to increase revenue, or save us money by saving us time and resources?
Is this small but meaningful—or a big lift with a big reward?
It works especially well in planning sessions where business and technical voices need to align fast because we are all using the same frame of reference.
Coaching business stakeholders
The power of this matrix is as a facilitation tool in building consensus.
✅ Everyone takes part in the scoring. For each category (business value, RROE, and time criticality), I ask each stakeholder to give a score, then discuss the values and reach a consensus.
✅ We use disagreement to explore assumptions. Gaps in scoring can reveal hidden pain points or fuzzy expectations. That’s where the best insights come from. When each stakeholder explains why they chose a value, the ensuing discussion facilitates a clearer shared understanding. I have even seen these discussions that caused the business owners to request that I remove their own proposals from the backlog!
✅ The product owner estiamtes effort. As a product owner embedded in the technical teams, I’ve become familiar with how they are likely to score effort during sprint planning. My estimates typically align well enough with theirs for this exercise. If in doubt, I assign a mid-level value of 8 and take an action item to check with my tech lead later.
✅ Encourage consistency across teams. I work with other product owners who have their own teams. We all use the same CRM system, though and have many stakeholders in common. Therefore, we defined common baselines for familiar work we had in common, so a stakeholder for one of my products could use the same scale when they were working with one of my peers.
Business stakeholder adoption came lightning fast after we introduced the matrix because they could have similar conversations about priorities no matter which product owner they were working with.
Your turn—how to make it yours
Here are some tips for adapting this matrix your business context.
Replace language with terms your business users recognize.
Add examples tied to your domain or industry—recent past examples of projects work best.
Use it for bugs, enhancements, tech debt, or new ideas.
Choose your own numbering system. I tried values of 1-4 at first, but there were too many nuances for us to have so few options.
Remember: WSJF works for problems to solve and opportunities to capitalize on. Using a scale of 0 to 21 gives enough room for situational nuance within the business context, and that makes it easier to rank the priorities, with the highest WSJF value being the clear top priority.
Final Thoughts
WSJF turns abstract prioritization into a thoughtful, interactive dialogue. It gives teams a shared vocabulary to surface what matters, supported by a mathematical equation.
The next time you face too many priorities, try asking, "What will it cost to delay this feature, relative to how hard it will be to implement?"
You might be surprised how quickly your top priorities emerge.
Want to try it with your team?
👉 Schedule time with me to discuss your needs!
