740 backlog items, a Monday reshuffle, and 35% of features nobody uses
Three years after launch, a B2B SaaS company has 740 open items in its product backlog. Of these, 210 carry a 'high priority' label, 130 come from a single enterprise customer's wish list, and about 60% are technical items described only as 'refactoring' or 'cleanup'. Nothing below the top 20 has been reordered in a year. The sales VP reshuffles the top of the backlog every Monday morning before refinement, usually in response to a phone call. Refinement takes three hours a week and produces acceptance criteria for about four items. The team runs two-week sprints and delivers roughly nine items per sprint. Analytics show that 35% of the items delivered in the last six months were never used by any customer. The PO is six months into the role and inherited the backlog; two stakeholders have started emailing developers directly because, they say, 'the backlog never changes'.
1. Assess this backlog against the DEEP criteria and give the PO a concrete 90-day plan.
Read the worked answer
DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritised. All four are failing.
- Prioritised: 210 items labelled high priority is not an order. Labels are not a ranking, and nothing below the top 20 has moved in a year, so the ordering carries no information.
- Emergent: nothing is ever removed. At roughly nine items per sprint the team can deliver around 230 items a year, so 740 items is a three-year queue. A backlog that long is a wish list, not a plan.
- Detailed appropriately: 60% of items are 'refactoring' or 'cleanup' with no outcome attached, so neither the team nor the business can judge them.
- Estimated: unclear, but four refined items per week against nine delivered per fortnight suggests refinement is too shallow and too late.
A 90-day plan: archive anything untouched for twelve months after notifying stakeholders; merge duplicates and split large epics; rank the top 60 by cost of delay or expected value; apply a ready-limit of roughly two sprints' worth of refined items; require a value statement for every item, including technical ones; publish the order and the criteria; measure adoption after release. Deleting is the PO's job - and not deleting is also a decision, with a cost.
2. The sales VP reorders the backlog every Monday, and one enterprise customer has submitted 130 items. How should the PO handle both?
Read the worked answer
The Monday reshuffle is a governance failure rather than a personality problem: there is no agreed ordering model, no visibility of the cost of churn, and no consequence for reprioritising. Three moves:
- Agree the criteria with the executive team - revenue at risk, segment size, strategic fit, effort, risk - and publish them. An order that follows stated criteria is much harder to overturn on a phone call.
- Set a cadence. Reprioritisation happens in a monthly window, not every Monday. An item can be inserted mid-cycle only by naming what it displaces.
- Show the data. Context switching has a cost, and the 35% unused rate suggests that responsiveness is not producing value. That is a more persuasive argument than 'stop doing that'.
For the enterprise customer, do not refuse - segment. Separate contractual commitments from wishes, group the 130 items into themes, quantify the revenue at stake, and negotiate a roadmap with dates and confidence levels. Promising 130 items individually is a promise nobody can keep.
The PO must own the order. Being responsive to stakeholders is not the same as being reordered by them; if the sales VP can reorder at will, the PO is a backlog administrator, not a Product Owner.
3. Sixty percent of the backlog is vague technical work, and 35% of delivered items are never used. What should the PO do about both?
Read the worked answer
Both symptoms point at the front of the funnel, not the team.
Technical items. 'Refactoring' with no outcome is unorderable, which invites either arbitrary inclusion or permanent deferral. Require each item to state its effect: reduced lead time, lower defect rate, reduced cost, risk removed. Then either express it as an outcome the business can value, or ring-fence a capacity slice (for example 20% of each sprint) for enablers ordered by risk. What must not happen is a separate technical backlog that competes with product work without a common currency.
Unused features. 35% unused means the team is delivering output that nobody adopts. Add discovery before an item is ready: problem statement, target user, success measure, and where possible a prototype or a thin slice. Add an outcome definition alongside the Definition of Done: what behaviour should change, and how will we know? Measure adoption after release and review it at the sprint review, not in a quarterly report nobody reads.
Then act on the data: retire or fix the features that show no use. A backlog should shrink as learning accumulates. A PO whose backlog only grows is not prioritising; they are accumulating.