Three Hundred and Eighty Items and No Answer on Value
A Product Owner manages an internal HR platform used by 4,000 employees. The Product Backlog holds 380 items. Sixty-five percent of them were raised by one regional HR director who emails requests directly to the Product Owner and escalates to the CHRO whenever they are not prioritised. Success is defined internally as 'items delivered': the team shipped 210 items last year, and the Product Owner reports that number monthly. Adoption of the platform is 34% of eligible employees, and the last two engagement surveys show satisfaction flat at 3.1 out of 5. The Sprint Review is a demo for two HR representatives, who watch and say little. A new CPO has just asked, 'What value did we get for those 210 items?' and the Product Owner has no answer.
1. What is wrong with how this Product Backlog is managed, and what would you change in the next 30 days?
Read the worked answer
The backlog is a request queue, not an ordered hypothesis about value. Three things show it. First, ordering is driven by who escalates, not by expected value or risk - 65% of 380 items from one source means the ordering reflects one person's voice. Second, the items are outputs with no stated outcome attached; nobody can say what would change in the world if an item shipped. Third, the success measure is throughput, which is guaranteed to rise while adoption stays flat at 34%, so the system cannot learn.
Within 30 days, feasible changes: write a product goal that names an outcome for a defined user group and the measure that will show it moved; cap the backlog by removing items with no owner, no outcome and no activity in twelve months, and by grouping the remainder into themes so people can see the shape of demand; take the top ten items and rewrite each as a problem plus a hypothesis plus one measurable success signal; establish a single intake route with published criteria; baseline three or four adoption and outcome measures by segment so the next Review has a comparison point. Reordering all 380 items is not the goal - making the top of the backlog trustworthy is.
2. How should the Product Owner handle the regional HR director, who originates 65% of the requests and escalates when not prioritised?
Read the worked answer
The director is a legitimate stakeholder with real problems and should not be managed by avoidance. But the Product Owner is accountable for ordering the backlog, and ordering by escalation pressure is a failure of that accountability, not a fact of life.
Start with the problem, not the requests: meet the director, find the two or three outcomes behind the sixty-five percent - regional compliance, manager self-service, whatever it is - and agree how progress on those outcomes will be judged. Then make the cost of the queue visible and non-accusatory: the lead time for a request today, the share of team capacity consumed by this source, and what has consequently not been done. Offer them a different role: not a submitter of items but a participant in Sprint Reviews where the outcome data is examined, and a partner on intake criteria.
Where escalation happens, respond transparently with the ordering rationale rather than a compromise that reorders the backlog to keep the peace; and secure explicit backing from the CPO for the product goal so escalation has somewhere to land. Giving one stakeholder a permanent override converts the backlog into a political artefact, and the cost shows up as a platform only 34% of employees use.
3. The CPO asks what value the 210 items delivered. How should value be inspected from now on, and what should the Sprint Review look like?
Read the worked answer
The honest answer today is that nobody knows, because nothing was instrumented. The remedy is to pick a small set of outcome measures tied to the product goal - adoption by segment rather than aggregate, task completion rates for the top employee journeys, time-to-hire or transfer cycle time, support ticket volume for HR processes - and report trend lines, not absolute snapshots. Distinguish leading indicators the team can influence within a Sprint from lagging ones that take quarters, and expect lagging measures to move slowly; a single quarter of flat data is not proof of failure.
Redesign the Sprint Review around inspection of value. Invite real users - employees and line managers, not only the two HR representatives - and start from the last increment's effect: what did adoption, task completion or ticket volume do, and what does that imply for the backlog? Then let those users try the new increment against their own work. The demo becomes evidence rather than the event itself. The Product Owner leaves with a reordered backlog and, crucially, a decision about what to stop doing: with 34% adoption, some of those 210 items are candidates for removal or replacement, and the Review is where that becomes discussable.