Establish what matters this cycle

Choose a small set of current objectives. You may be stabilizing an existing workflow, enabling a new customer group, or reducing the effort required to operate the system. Explain how these objectives affect the order of work.

A request that matters eventually may not support the current objective. Keeping it visible without scheduling it is a legitimate outcome. Do not make every item urgent merely because somebody important asked for it.

Compare impact, evidence, and effort

For each serious candidate, record who benefits, what improves, and what evidence supports the expected improvement. Include the cost of waiting when there is one. Mark estimates as estimates and describe the unknowns that could materially change them.

Use a lightweight scoring method if it helps discussion, but do not mistake a calculated number for a measured fact. Two items with similar scores may differ sharply in reversibility, dependencies, or confidence. Those differences deserve explicit judgment.

Leave room for operational work

Maintenance and reliability tasks often lack an obvious new screen to demonstrate. Explain the consequence they address: slow recovery, fragile releases, repeated support work, or a dependency that the team cannot safely update.

Keep capacity for investigating new information rather than scheduling every available hour. Review priorities when evidence changes, and record why a previously planned item moved. That history makes prioritization more understandable to people whose requests are waiting.

At the end of a planning session, the team should know the next few outcomes to pursue and why. It does not need a false ordering of every conceivable feature for the next year.

Illustrative scenario

A practical example.

Suppose a backlog contains a visual refresh, a broken export, and automated reminders. The export problem affects the finance team’s weekly reconciliation; the reminders might reduce follow-up work; the refresh has no stated operational outcome. These are different kinds of work, so a single “high priority” label is not useful.

Describe the effect of delaying each item and the evidence behind that assessment. A short investigation may reveal that only one export format is broken, allowing a small fix before tackling reminders. Keep uncertainty visible: an estimated benefit is not the same as a measured failure. After choosing the next items, explain what was deferred and when that choice will be revisited.

Put it into practice.

  • Separate urgent defects, necessary maintenance, and improvements with uncertain benefit.
  • Record the cost of delay and any dependency that changes the order.
  • Keep the next few choices clear instead of pretending the entire backlog is scheduled.

Working through a similar decision?

Tell us about your project