Backlog Triage: Choose the Next Five Projects

Choose the next five projects as an ordered decision queue, then start only the work your team can actually carry. Separate mandatory obligations from discretionary ideas, identify dependencies, and put one named owner and a testable outcome on every candidate before debating its priority.

An ordered shortlist helps a team decide what happens next; it is not an instruction to launch five projects at once. First remove obsolete requests and split vague proposals. Then compare the remaining work against one current goal, available capacity, consequence of delay, and evidence of value. Make uncertainty visible instead of disguising guesses as precise scores.

The original backlog illustration uses a funnel leading to five ordered cards and a separate, limited active-work lane. It distinguishes selection from starting. The worksheet below is an editorial planning tool, not a scientifically validated predictor of project success.

Write one sentence describing the outcome the team is trying to improve over the next planning period. For example: “Reduce the time between a new customer signing and completing the first usable setup.” A request to add ten dashboard features can then be discussed in relation to that outcome rather than the enthusiasm of its sponsor.

This does not mean every obligation must serve the same improvement goal. Contractual, security, safety, and regulatory work may need capacity for independent reasons. Put those obligations in view with the actual requirement and responsible reviewer. Do not allow an unsupported claim that something is “compliance” to settle the argument, but do not let a lightweight scoring exercise overrule a genuine duty either.

The 2020 Scrum Guide describes an ordered, evolving Product Backlog and a Product Goal that gives direction. The approach here borrows the useful distinction between a goal and a list of work. It is a general project-triage exercise, not a claim that every organization should implement Scrum or that this five-item format is part of that framework.[1]

Read the backlog once for duplication and expiration. Two requests may describe the same underlying problem with different proposed solutions. Combine their evidence while retaining the people affected. A request whose triggering event has already passed may be removable, or it may need a new statement of why it still matters.

For each remaining item, identify the affected person, current difficulty, proposed outcome, and evidence available. “Automate operations” is not ready for comparison. “Reduce the manual re-entry of approved purchase orders between these two systems” gives the team a narrower question. If no one can explain the pain without referring to a proposed feature, send the item back for clarification.

Separate a discovery task from a delivery commitment. Interviewing three internal users to learn why a report is ignored is different from rebuilding the reporting system. Discovery can be a small, explicit candidate with a learning outcome, an owner, a time boundary, and a decision it will inform. It should not become an indefinite holding area where uncertain projects quietly consume capacity.

Use a small set of discussion questions: What changes if this succeeds? Who experiences the improvement? What happens if we wait? How confident are we? What capacity and dependencies does it consume? Have the team record answers in plain language before attaching numbers.

If you use scores, state what the scale means. A value score of four is not four dollars, four hours saved, or a measured probability of success. Treat closely scored candidates as a conversation requiring judgment. A dramatic multiplication formula can make weak estimates look authoritative without adding any evidence.

Consider an illustrative pair: fixing a documented invoice defect versus adding a new sales dashboard requested by one executive. The first has visible error examples and an operational consequence; the second may have strategic value but needs a clearer decision it supports. The right answer depends on the organization, yet the comparison becomes more useful when confidence and evidence are visible alongside the promised benefit.

Draw an arrow whenever one candidate needs another decision or deliverable first. A dashboard cannot be accepted if the team has not agreed on the metric definition. A campaign cannot launch if its claims require review that nobody has scheduled. These dependencies should change the order or scope before work begins.

Distinguish real prerequisites from habitual sequencing. Ask the owner of a claimed dependency what specifically must be available and whether a smaller version would allow progress. Sometimes a sample dataset is enough for a design test; sometimes an actual approved agreement is essential. Record the answer rather than labeling everything “blocked by another team.”

The five selected candidates should therefore form an intelligible order. Item two may be next because it becomes possible after item one, while item five is a useful reserve option if an external dependency delays item three. Do not promise dates for all five unless capacity and uncertainty support those commitments.

List the people and specialist reviews required for the first candidate. Compare that demand with existing work, leave, support responsibilities, and other commitments. If the same person is already a bottleneck on two projects, adding a third owner label does not create more time.

Choose an active-work limit that the team can test and review. Starting one project may be appropriate for a small team; another team may have independent capacity for more. The number should reflect the work system, not the fact that this article asks for a shortlist of five. Keep waiting work visibly queued instead of calling it active to reassure a sponsor.

Define what happens when an urgent request arrives. Identify who can change the order, what evidence is required, and which existing commitment will move. An emergency lane with no tradeoff simply becomes an unbounded second backlog. Record the displaced work and communicate the changed expectation to its owner.

Before starting, complete this sentence: “We will consider this project complete when this person can verify this outcome using this evidence.” A billing repair might require finance to verify agreed test cases and a documented observation period. A discovery project might end with a decision memo that either supports delivery or explains why the idea should stop.

Name the reviewer and book their availability early. Otherwise work can finish technically and remain unresolved because the person who accepts it has not seen it. Acceptance should be specific enough to prevent endless polishing, while leaving room to respond to genuine new information that affects correctness or usefulness.

Hold a short review after completion, a material dependency change, or a significant new obligation. Compare expected and observed effort, waiting time, and outcome. Record why the order changed. The aim is to learn which assumptions were wrong, not to punish the team for updating a forecast.

Must the shortlist always contain five items?.

No. Five is a practical discussion boundary for this exercise. If only three candidates are clear enough, retain three and clarify the others. Filling empty positions with vague work undermines the purpose of triage.

What if two sponsors disagree?.

Ask the accountable decision-maker to choose using the shared goal, evidence, and constraints. Record the tradeoff and review trigger. A decision can be explicit even when there is no universally correct ranking.

What should I do in the next 20 minutes?.

Take ten backlog entries, remove duplicates, and rewrite the five clearest as outcomes with owners. Identify which one could start with current capacity and what would prove it complete. Use the ResultsBreakthrough resource library to support the next execution conversation.

This is an evidence-informed planning method, not a guarantee of speed, revenue, or team performance. Test it against your own results and adapt the review cadence to the consequences of the work.