Prioritise a small backlog by removing stale work, identifying genuine constraints and comparing the remaining items using evidence, effort and dependencies. Choose the next useful piece of work and record why. A score can help structure discussion, but it cannot override an essential prerequisite or replace an accountable decision.
Start by making the backlog smaller
Gather candidate work in one place and check each item for a current problem, an owner and a next decision. Merge duplicates. Remove requests that no longer apply and record the reason if others rely on them. Keep an idea for future research only when there is a plausible question to answer; indefinite storage should not masquerade as a delivery commitment.
Separate work that is ready to choose from work that is too uncertain to estimate. “Improve client onboarding” may need a workflow observation before it becomes implementation work. A small research task can be the highest-value next action when the alternative is building around an untested assumption.
The former Trajectory product discussed this distinction in its historical “icebox” approach. Our sourced history section explains that context. Today’s process does not have to reproduce that product’s terminology.
Identify what cannot be traded away
List dependencies and mandatory constraints before weighing desirable outcomes. A confirmed contractual deadline, a confidentiality boundary and an access-removal defect need different treatment from a cosmetic request. Name the person who can confirm an obligation and retain its source. Do not label a stakeholder preference mandatory just because it was expressed firmly.
If the team cannot satisfy a genuine constraint within its capacity, escalate the scope, timing or approach. Giving the item a very large score does not create capacity. Likewise, a feature that depends on reliable ownership data cannot be made viable by ranking it above the data work.
Work through a five-item backlog
Illustrative case: a client-delivery team has limited capacity for its next work period. The evidence below is fictional and demonstrates how to reason; the effort bands are estimates for this scenario, not benchmarks.
| Item | Evidence and uncertainty | Effort estimate | Dependency | Decision |
|---|---|---|---|---|
| A: Remove former contractor access | Access review identifies an active account that should be removed | Small | Confirm ownership of connected automations | Act first; verify removal and transfer dependencies |
| B: Make request ownership compulsory | Sample handoffs suggest unassigned work; sample size is limited | Small to medium | Agree fallback owner | Choose a small trial after A |
| C: Automatic handoff reminders | Team expects reminders to reduce missed work; untested | Medium | Reliable ownership and notification preferences | Defer until B provides evidence |
| D: Client reporting dashboard | One stakeholder requests a richer view | Large | Stable status definitions and visibility rules | Investigate the underlying decision first |
| E: Change board colours | Preference from one internal user | Small | None | Defer unless an accessibility issue is established |
A comes first because an access boundary has been identified, even though it may not increase visible output. B is a bounded way to learn whether ownership is the actual bottleneck. C depends on B. D has weak evidence and broad scope. E is cheap, but cheap work can still displace a more important task.
If E turns out to describe insufficient contrast for a colleague, its meaning changes. It becomes an accessibility requirement with new evidence rather than a decorative preference. Reprioritisation should respond to that evidence, not defend the original ordering.
Use numbers as a conversation aid
An impact-versus-effort table can expose disagreements. For example, label impact low, medium or high and effort small, medium or large, then state the evidence behind each judgement. This is an illustrative editorial framework, not a validated scientific measure. Avoid multiplying uncertain estimates into a precise-looking answer.
When participants disagree, ask what observation would distinguish their assumptions. The delivery lead may expect reminders to help, while coordinators report that ownership is unclear. Observe the handoff before building the reminder. A short evidence-gathering task can reduce the chance of automating the wrong process.
If you use weighted scores, keep the scales consistent and examine sensitivity. Does a small change to a weight reverse the order? If so, the ranking is fragile. Record that instead of announcing a winner to several decimal places. Never use velocity to rank individuals or compare unrelated teams; different work and estimation practices make that interpretation unreliable.
Keep a short decision log
Decision: Trial compulsory ownership for incoming requests. Owner: Delivery lead (illustrative role). Reason: Unassigned requests appear in the sample handoffs. Constraints: Complete access removal first; keep client visibility unchanged. Assumptions: One fallback owner can cover absence. Evidence to gather: New requests with a valid owner; exceptions and reasons. Deferred: Reminders and dashboard until ownership is tested. Review trigger: Trial ends or an essential requirement fails. Decision at review: Continue / revise / stop, with supporting evidence.
The log should explain what someone needs to know later, not reproduce the whole meeting. Preserve a previous decision when changing direction so a new colleague can understand why the earlier choice was reasonable with the evidence available then.
Select work that fits actual capacity
Account for support, maintenance, leave and ongoing administration before allocating new work. Select fewer items when there is significant uncertainty. Starting every high-priority item at once can create dependency queues without producing an accepted outcome. The useful unit is work that can reach its acceptance check, not work that merely enters an “in progress” column.
A shared spreadsheet can support this process if the team can see ownership, dependencies and decisions. Changing the planning tool is justified only when the current system prevents a needed behaviour. Try a clearer review routine before assuming the backlog needs another application.
Connect selected items to the roadmap outcome and publish the decision through a durable async update. At the next review, compare the new evidence with the assumption that made the item worth doing.