Backlog and prioritisation
The top-ranked backlog item depended on an untested value assumption.
Import wizard v2 looked attractive on value and effort. The effort estimate was credible, but the value score depended on an explanation for churn that the team had never tested.
A prioritisation score is only as reliable as the assumptions used to create it.
Steps 01–02
Make backlog items comparable by separating value from effort
FlowDesk's Q4 backlog contained six epics and roughly two hundred smaller items.
Backlog discussions become difficult when different items are judged using different criteria. Two people can disagree about the same epic for weeks without identifying whether they disagree about expected value, effort, risk or something else.
FlowDesk scored value and effort separately, then calculated ROI as value divided by effort. The score did not settle the decision. It made the disagreement more specific because each input could be questioned directly.
That specificity was the useful part. Instead of arguing that an epic was simply “important”, people had to explain why they had assigned a particular value or effort score.
Effort estimates describe the work you expect to do. Value estimates make a claim about what you expect to happen afterwards.
Steps 03–04
Use a visible cutline to make capacity decisions explicit
The cutline records what the team intends to fund with the capacity available for the period.
Plotting the six epics by value and effort showed three quick wins, one larger strategic bet, one lower-priority item and one item that was hard to justify. Two of the quick wins depended on the same underlying belief.
The team then placed a cutline based on available capacity. That made “not this quarter” an explicit planning decision rather than an informal judgement that had to be renegotiated every week.
Custom shift templates remained below that line for three consecutive quarters. The decision could be revisited when the evidence or capacity changed without restarting the discussion from scratch.
A backlog becomes more useful when it shows what the team has chosen not to fund as well as what it plans to build.
Step 05 · the honest part
Check the assumptions behind the highest-ranked items
A scoring model can rank the inputs correctly and still produce a poor decision when an important input is unsupported.
Import wizard v2 had a value score of 80 and an effort score of 20, producing an ROI of 4.0. It sat comfortably above the cutline and at the top of the ranked list.
The effort estimate came from engineering work the team understood. The value score depended on a different claim: that setup difficulty was the main reason new accounts churned. That claim had not been tested.
Before committing the item to a sprint, the team checked the assumption supporting its value score. A two-week test was cheaper than building the epic and discovering later that the diagnosis was wrong.
A ranked backlog shows which items score highest under your current beliefs. Important assumptions still need evidence.
Step 06
Break down the work after the underlying decision is supported
The validated epic became two features and three stories, with the objective and experiment still linked above them.
Only the validated epic was broken down further. EPIC-31 became two features and three user stories, with the objective and experiment still connected to the delivery work.
The user stories could refer to the dispatcher because discovery had already described that user and the problem they were trying to solve.
Day-to-day status remained in the engineering tracker. Shorter Loop kept the objective, evidence and decision linked to the work without asking engineers to maintain another delivery system.
One backlog, two views
Use the matrix and list as two views of the same backlog
Moving an item in the matrix changes the same underlying score shown in the list, and editing the score in the list moves the item in the matrix. The prioritisation view and the working backlog stay on the same data.
Fair questions
What people ask about backlog prioritisation
- Isn't value ÷ effort too crude?
It is intentionally simple. The purpose is to make the inputs visible and discussable. More elaborate formulas add little value if nobody can explain or challenge the numbers used in them.
- Does this replace our sprint tool?
No. Epics, features and stories can remain in the tracker your engineering team already uses. Shorter Loop holds prioritisation and product context while delivery status stays in the engineering system.
- Who decides where the cutline goes?
The team decides. The cutline records the amount of work it intends to fund with the capacity available and can be moved when capacity or priorities change.
- What stops the highest-paid opinion from winning anyway?
Nothing prevents an executive from overriding the ranking. Shorter Loop makes the override visible: which value changed, who changed it and when. That gives the team a record it can revisit later instead of relying on memory.
- Do we need three levels of hierarchy?
Use as many as the work needs. Small teams often stop at features. The level that matters most sits above the hierarchy: the objective the epic reports to.
- How long before this is worth anything?
It depends on how fast you can connect what you already have. For a ten-person team that has typically taken about five days.
Review the assumptions behind your highest-priority backlog items.
Rank the work, set the cutline, then inspect the value assumptions behind the items above it. A short test can be cheaper than committing a quarter to the wrong explanation.
FlowDesk is the Shorter Loop demo workspace. You can inspect the scoring, cutline, assumptions and delivery links used in this example.