# How to Prioritize a Backlog Without a Committee

> How to prioritize a backlog on Shopify projects: one scoring pass, one owner, and a weekly cadence instead of a prioritization meeting.

_Published: 2026-10-16 · CommerceCopilot_

## Prioritization by meeting is not prioritization

Most Shopify agencies already know how to prioritize a backlog in theory. In practice, the backlog gets prioritized by whoever shouted most recently: the client who emailed twice this morning, the developer who wants the interesting ticket, the account manager who promised something in a call nobody wrote up. The usual fix is a weekly prioritization meeting, and the usual result is an hour of five people relitigating the same ten tickets, ending with an order that holds until the next client email.

The meeting is not the fix. The meeting is the symptom. A backlog needs a committee only when nobody can tell, by looking at a ticket, why it ranks where it does. This post lays out a backlog prioritization process that replaces the committee with three cheaper things: a scoring pass anyone can check, a single owner, and a fixed cadence.

## What prioritizing a backlog actually decides

A backlog order is not a statement about what matters. Everything in the backlog matters to someone, or it would not be there. The order is a statement about sequence: given that the team ships a fixed amount per week, what gets built first, and what knowingly waits.

That reframing does real work. "Is this important?" invites a debate nobody can win, because importance is relative to whoever is asked. "Does this ship before or after the search filter ticket?" is answerable, and the answer exposes the actual trade-off. Agencies feel this more sharply than product teams because the backlog spans paying clients with different contracts, launch dates, and tolerance for waiting. The sequence is the product you are selling; a client who understands why their ticket is third in line is calmer than one who suspects it is third because they complained least.

## How to prioritize a backlog: the working process

The process below assumes a single delivery team working across one or more Shopify projects. It takes about an hour to set up and roughly fifteen minutes a week to run.

### Step 1: make the backlog scorable before you score it

You cannot rank what you cannot read. A backlog where half the entries say "fix cart issue" or "homepage improvements (see email)" will defeat any framework, because the score of a ticket nobody understands is a guess wearing a number. Before the first scoring pass, every candidate ticket needs a scope, a why, and acceptance criteria, which is the same bar as a dev-ready ticket. If your tickets are not there yet, start with [how to write development tickets a team can build from](/blog/how-to-write-development-tickets); prioritization inherits whatever quality the tickets have.

This step is also where most of the backlog disappears, which is the point. A ticket that nobody can state a why for, after two minutes of trying, is not a low-priority ticket. It is not a ticket at all.

### Step 2: pick a scoring model and keep it cheap

Two frameworks cover nearly every agency case, and both are simple enough to run in a spreadsheet column.

[RICE](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers), built by Sean McBride on Intercom's growth team, scores each item as reach times impact times confidence, divided by effort. Its quiet strength is the confidence term: an exciting idea with no data behind it gets discounted to 50%, which is the framework's built-in defense against the loudest voice in the room. For agency work, read "reach" as how much of the client's traffic or revenue touches the change, and keep effort in developer-days rather than person-months.

MoSCoW, introduced by Dai Clegg at Oracle in the 1990s and later adopted into the DSDM method, sorts items into must have, should have, could have, and won't have this time. It was designed for exactly the agency situation: time and budget fixed, scope negotiable. Its strength is the fourth category. A backlog with a real "won't have this time" list has already had its hardest conversations.

Use MoSCoW when the question is what makes a fixed launch date; use RICE (or a lighter value-versus-effort pass) for ongoing retainer backlogs where everything could ship eventually and the question is order. Do not blend them, and do not let scoring take longer than fifteen minutes per pass. The score exists to make disagreement visible, not to be correct to two decimal places.

### Step 3: give the ranking one owner

A score settles most tickets. The ties, the exceptions, and the client politics need a human decision, and that decision needs exactly one owner: a project lead, a producer, whoever holds the client relationship and understands delivery. Everyone can feed information in. One person sets the order, and the order stands until the next pass.

This is the part that actually replaces the committee. The committee existed to diffuse responsibility for disappointing someone. An owner with a visible scoring pass behind them can disappoint someone and show their work.

### Step 4: cut the tail, not just sort it

Sorting a 400-ticket backlog produces a sorted 400-ticket backlog, which nobody will scroll past item thirty of. Anything that has sat unranked for two scoring cycles with no advocate gets closed with a note, not kept "just in case." A closed ticket can be reopened in thirty seconds the day someone actually misses it; a 400-item backlog costs attention every single day, and a board people have silently agreed to ignore is how [a clean tracker setup rots](/blog/jira-for-shopify-agencies). A healthy agency backlog is rarely more than two or three sprints deep, with everything else living in a parking lot the team does not look at weekly.

### Step 5: re-prioritize on a cadence, not on demand

New requests land daily; the ranking changes weekly, at a fixed time, in one pass. Between passes, new tickets get a provisional slot from the owner and nothing else moves. This single rule kills the churn where every client email reshuffles the week. Genuine emergencies (the checkout is broken, a launch is tomorrow) skip the queue, and the definition of an emergency is written down in advance precisely so that "the client is annoyed" does not qualify.

## Priority signals specific to Shopify work

Generic frameworks miss inputs that move rank on agency Shopify projects specifically, so fold these into the scoring pass:

- **Distance from the money path.** A bug on the product page, cart, or checkout outranks a visually identical bug on the FAQ page, because one sits on the revenue path and the other does not.
- **Calendar locks.** Peak-season code freezes and promotion dates are hard deadlines that invert normal rankings: a medium-value ticket that must land before a freeze outranks a high-value ticket that can wait.
- **Dependency unblocking.** A small ticket that unblocks three others carries their weight, not its own. This is invisible unless dependencies are recorded on the tickets.
- **Blast radius of waiting.** Some tickets get more expensive the longer they wait, like a deprecated API or an app the client wants replaced before renewal. Flat value scores miss this; a delay note on the ticket catches it.

## Keep the ranking where the work lives

A ranking that lives in a spreadsheet while the team works a tracker is two sources of truth, and one of them is always stale. The backlog order belongs in the tool the developers pull from, which for many agencies means Jira; a [Jira setup that matches how Shopify work breaks down](/blog/jira-for-shopify-agencies) makes the ranked backlog the same list the sprint gets built from, instead of a document that gets reconciled against it.

## Where CommerceCopilot fits

Step 1 is the expensive one: a backlog is only rankable if every ticket arrives with scope, a why, and acceptance criteria already written, and at most agencies that translation work falls to a senior person who does it late and inconsistently. That is the step CommerceCopilot's Business Analyst agent handles. It reads briefs, call transcripts, and connected channels, and drafts a dependency-mapped backlog with acceptance criteria structured on every ticket, flagging open questions instead of guessing, with a human reviewing the draft before anything reaches the tracker. The [brief-to-tickets walkthrough](/docs/your-first-brief-to-ticket-project) shows that review step.

Because the tickets land with dependencies already linked, the dependency-unblocking signal above stops being archaeology, and because confirmed tickets are created directly in [your connected Jira project](/docs/jira) in your own statuses, the ranked backlog and the working backlog are the same list. The ranking decision stays with your project lead; the agent's job is making sure every ticket under that decision is readable enough to rank.

## FAQ

### How often should a backlog be re-prioritized?

Weekly for active retainers, or once per sprint if you run fixed sprints. More often than that and the ranking churns faster than the team can ship against it; less often and the backlog drifts from reality. The cadence matters more than the frequency: a fixed slot the team can rely on is what stops ad hoc reshuffling.

### Who should prioritize the backlog at an agency?

One named owner per client or team, usually the project lead or producer, informed by a scoring pass everyone can see. Developers and account managers feed in effort estimates and client context, but a ranking owned by a group is owned by nobody, which is how backlogs end up re-argued weekly.

### Is RICE or MoSCoW better for agency work?

They answer different questions. MoSCoW fits fixed-scope projects with a launch date, because its "won't have this time" category forces the scope conversation early. RICE fits ongoing retainer backlogs where the question is sequence rather than inclusion. Pick per engagement, and keep whichever you choose cheap enough to run in fifteen minutes.

### What about tickets the client insists are urgent?

Put the request through the same pass as everything else, and show the client the ranked list with their ticket on it. Most "urgent" requests survive contact with an explicit trade-off ("this ships first and the size guide moves out a week") about half the time. The ones that survive were probably genuinely urgent; the written emergency definition covers the rest.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/how-to-prioritize-shopify-development-backlog