Four Hundred and Eighty Items, Ordered by Date
A UK council's permits service has 480 open Product Backlog items built up over four years, ordered largely by the date each was raised. Refinement is a standing four-hour Thursday session in which the team estimates every item until roughly 200 sit in a 'ready' column. There is no current Product Goal; the last one, 'modernise the platform', was closed a year ago and never replaced. The team delivers about 22 points per Sprint while roughly 30 new items arrive each month. Near the bottom of the backlog sit a two-point accessibility fix affecting about 4,000 screen-reader users, and a request from the cabinet office. Sprint Planning frequently overruns because the top items have never been discussed with the Developers.
1. Diagnose the backlog management problems and state what the Product Owner should do first, second and third.
Read the worked answer
Problems, in order of damage:
- No Product Goal. With nothing to order against, 'date raised' wins by default. Ordering by age is ordering by nothing.
- Over-refinement. Estimating 200 items four hours a week produces guesses about work that will change before it is built. Detail decays; only the top needs to be ready.
- Intake exceeds throughput. Thirty in, roughly 22 points out. The backlog is a queue that can only grow, and nothing is ever refused.
- Blind Sprint Planning. Planning is doing refinement it should not have to.
Sequence: agree a Product Goal with service owners and the cabinet office - weeks, not months; reorder the whole backlog by value and risk against that goal, deleting or parking anything that does not serve it; introduce a written triage rule for new arrivals; shrink refinement to about an hour on the top two Sprints' worth. Reordering 480 items is a one-off exercise - do it with the Developers, not for them.
2. The cabinet office request arrives in the same week the accessibility fix is raised. How should the Product Owner handle both relative to the Sprint Goal?
Read the worked answer
Decide, and decide in the open. Both items are small; the real questions are what they displace and what the Product Goal says.
- Test both against the Product Goal. If the cabinet office request genuinely serves it, it goes near the top. If it is an unrelated favour, say so and offer a date rather than a silent yes.
- The accessibility fix is high value per point: two points for 4,000 users who currently cannot complete a task, plus likely compliance exposure. At the bottom of a backlog ordered by date it will stay there forever, because nothing promotes it.
- The PO may reorder the Product Backlog at any time. The PO should not rewrite the current Sprint Goal mid-Sprint. If the cabinet office item must enter the running Sprint, the PO negotiates with the Developers about what leaves, and the Sprint Goal is re-examined honestly rather than quietly stretched.
- Record the decision and its reason where stakeholders can see it. The recurring failure here is invisible ordering, not wrong ordering.
3. What should this team stop doing, and what should replace it?
Read the worked answer
Stop three things: estimating the entire backlog, running refinement as a four-hour standing meeting, and accepting every incoming item as backlog debt.
Replace them with:
- Just-in-time refinement of roughly the top two Sprints' worth, so effort is spent on work that will actually be built.
- A written triage rule: what gets in, what gets parked, who decides, and when parked items expire.
- A visible 'we are not doing this' list shown to service owners, so the trade-off is a leadership conversation rather than an invisible backlog.
Also stop reporting delivered points as if they were progress. With intake at 30 items and output at 22 points a Sprint, the backlog is growing even in a good Sprint. That is a capacity and prioritisation problem the team cannot solve from inside, and it should be on the table with whoever owns the service.