Priorities
How to prioritise development work when everything important is already marked urgent. MoSCoW, RICE and WSJF, with worked examples and practical uses.
Everything is a priority
On a big project, there’s always more work than the team can deliver. The client wants new features. The business wants better conversion. Engineering keeps bringing up technical debt, and the release is already looming. Every task has someone convinced it’s the most important thing on the planet. You can mark everything as high priority. It won’t magically create more capacity.
Prioritisation frameworks exist for exactly this kind of mess. They help you agree on essential scope, compare the expected value of initiatives and decide what gets done first. I’ll walk through three approaches using an online store that needs payment fixes, better search, a wishlist and an updated shipping integration. All at once, naturally.
MoSCoW: agree on the essentials
| Category | Meaning |
|---|---|
| Must Have | Essential to achieving the release goal |
| Should Have | Important, but can wait if necessary |
| Could Have | Desirable if capacity allows |
| Won’t Have this time | Explicitly out of scope for this release |
Say the store is getting ready to launch. Fixing a critical payment bug is a Must Have. Improving search that already works is a Should Have. A wishlist is a Could Have. The shipping integration is less straightforward. If the partner is retiring the old API before launch, the update becomes a Must Have. If not, it can wait.
MoSCoW is particularly useful when agreeing requirements with a client and planning a defined delivery scope. Don’t dump everything into Must Have. That rather defeats the point. These categories tell you what’s essential, not the exact order of development. Dependencies and deadlines still need a say.
RICE: compare the expected value
RICE scores product initiatives using four factors: Reach, Impact, Confidence and Effort.
RICE = (Reach × Impact × Confidence) / Effort
The team is choosing between improving search and adding a wishlist. We’ll use illustrative analytics data, monthly reach, a relative impact scale and effort in person-months.
| Factor | Search | Wishlist |
|---|---|---|
| Reach | 4,000 | 2,000 |
| Impact | 2 | 1 |
| Confidence | 80% | 50% |
| Effort | 2 | 1 |
| RICE | 3,200 | 1,000 |
Search scores higher. It takes more effort, but the expected value is substantially greater. The wishlist’s lower confidence score tells us there isn’t enough evidence yet that people actually want it.
RICE is useful for comparing product bets, but it needs decent inputs. If your impact estimate comes entirely from “I reckon users will like it”, the final number will look far more convincing than it deserves. A high RICE score doesn’t make essential technical work or critical bug fixes go away.
WSJF: the cost of waiting
WSJF stands for Weighted Shortest Job First. It sequences work based on the cost of delaying it. SAFe is one framework that uses this approach.
WSJF = Cost of Delay / Job Size
Cost of Delay is a relative estimate of the cost of waiting. Job Size is the relative size of the work, used as a proxy for duration. In SAFe, Cost of Delay combines user-business value, time criticality, and risk reduction and/or opportunity enablement.
| Factor | Shipping integration | Search | Wishlist |
|---|---|---|---|
| User-business value | 5 | 8 | 3 |
| Time criticality | 8 | 3 | 1 |
| Risk reduction / opportunity enablement | 5 | 2 | 1 |
| Cost of Delay | 18 | 13 | 5 |
| Job Size | 3 | 5 | 2 |
| WSJF | 6.0 | 2.6 | 2.5 |
The shipping integration comes first. Better search could deliver more value to users, but delaying the API update could cause problems at checkout. Given the relatively small job size, putting off the integration makes little economic sense.
WSJF helps when major initiatives are competing for capacity, especially if external deadlines and the consequences of delay matter. The people involved still need to agree on the scores. Technical dependencies need to be considered before anyone signs off on the plan.
Three frameworks, three different jobs
| Framework | What to use it for |
|---|---|
| MoSCoW | Agree on the essential release scope |
| RICE | Compare the expected value of product initiatives |
| WSJF | Sequence work for the best economic outcome |
You can combine them. Start with MoSCoW to agree on the must-have functionality. Use RICE to compare additional product initiatives. Then factor in the cost of delay through WSJF when sequencing the work.
The complexity of the tool should match the scale of the problem. If the team and client have already agreed on ten clear requirements, a whole scoring system probably won’t help. For a product with dozens of competing initiatives, transparent criteria make decisions easier.
Lovely numbers. Now what?
Every prioritisation exercise needs a reality check. A high score doesn’t guarantee available capacity, agreed requirements or the technical ability to start building. Once the calculations are done, the PM checks dependencies, specialist availability, budget and external constraints. Revisit priorities when the project changes in a meaningful way. New requirements, critical bugs, shifting deadlines or changes in user metrics can completely overturn the original estimates.
Frameworks help you make a case for decisions. They don’t make those decisions for the business or the team. If the scores come straight from a manager’s gut, it’s the same old guesswork. Just with formulas and a bloody lovely spreadsheet.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.