One Hundred and Forty Stories and No Vertical Slices
GridWorks Utilities is rewriting its billing platform. The backlog holds 140 items, most of them component-level: build address validation service, create database schema for tariffs, refactor metering adapter. One item, customer self-service portal, is estimated at 20 weeks. Refinement produces estimates only when the whole team attends the single 90-minute weekly session, and half of it is spent re-explaining context. Velocity has fallen from 34 to 21 points over five sprints, 25% of each sprint's scope carries over, and there is no definition of ready. The product owner prioritises by whoever shouted loudest in the last steering group. A regulator has fixed a date five months out for a specific outcome: customers on variable tariffs must be able to receive and query a tariff-change notification before it takes effect. Three of the 140 items relate directly to that outcome.
1. What would you do with the 140-item backlog in the next two weeks, and why?
Read the worked answer
Stop treating the backlog as a decomposition of a chosen solution. Run a story-mapping workshop with the product owner, a billing operator and two team members: user activities across the top, and beneath them the slices that deliver each activity end to end. Anchor the map on the regulatory outcome, then identify the thinnest slice that lets a variable-tariff customer receive and query a notification - even if part of it is manual behind the scenes for the first release.
Classify the 140 items. Many are implementation tasks the team should own under stories, not backlog items competing for priority; retire or fold them. Keep genuine user or operational outcomes, and rank the near-term slice using cost of delay or weighted shortest job first, since the regulator's date creates a steep, non-negotiable delay cost. Make the trade-off explicit: everything not on the path to the notification is deliberately below the line, and the product owner records that in steering so the displacement caused by shouted requests becomes visible.
The aim in two weeks is not a perfect 140-item backlog. It is a coherent, defensible next three sprints aligned to a hard outcome, which is what the current list cannot provide.
2. How would you split the 20-week customer self-service portal item?
Read the worked answer
A 20-week item is a product, not a backlog item, and its size is itself causing the estimation bottleneck - nobody can reason about it, so it sits at the top absorbing attention.
Split along user journey steps first: view balance, view bill, query a charge, update contact details, set notification preferences. Then split each step by business rule variation, such as single tariff versus multi-site, and by data direction, read-only before write. Then consider a manual-before-automated split for the parts where the team wants early feedback, for example staff-triggered notifications before scheduled ones. Choose the particular split by asking which slices get the regulator-facing outcome into customers' hands soonest and reduce the biggest uncertainty.
Check each candidate against INVEST and against the definition of done. Avoid splitting by layer, with a user-interface sprint followed by an API sprint, because that reproduces the integration risk and carryover already visible at 25%. Every slice should change something a customer or an operator can actually see, and should be demonstrable at sprint review.
3. What do you tell the product owner about prioritisation, and what goes into the definition of ready?
Read the worked answer
On prioritisation: say that ordering by volume of voice is a governance risk in a programme with a fixed regulatory date, because it hides the trade-off until it is too late to manage. The product owner keeps the decision, but the BA supplies options and consequences: a published order with cost of delay, a visible not-before list, and the explicit statement of what a shouted request displaces. That is influence through transparency, not a challenge to authority.
On the definition of ready, keep it short and decision-focused: the story names the user and the outcome; acceptance criteria have been discussed with at least one tester; dependencies are identified; the slice fits comfortably inside a sprint; any experience or rule decision needed to build it has been made; the team can estimate it without the entire room present. Nothing enters ready with an open question that has no owner.
Also fix the ceremony, because the single 90-minute session with everyone present is the real bottleneck. Move to two shorter refinement sessions per week with the subset who can actually answer questions, and reserve the full-room slot for estimation of items already prepared.