During backlog refinement for a utility billing portal, the epic labeled ‘payments’ is still too large for one iteration. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
An epic named ‘payments’ is like a grocery list that just says ‘food’—you can’t shop it in one trip. Refinement chops it into baggable stories: card pay, ACH, receipt email, and so on.
Full Explanation
During backlog refinement for a utility billing portal, an epic labeled “payments” that is still too large for one iteration should be split into smaller, independently valuable user stories that can be ordered and delivered. Splitting restores adaptive flow: the team can deliver partial payment value sooner, learn from production use, and reorder remaining slices without waiting for a monolithic payments package. Oversized epics hide risk, block honest forecasting, and delay civic billing outcomes residents depend on.
Hiding the epic from stakeholders until after go-live fails conceptually because concealment prevents prioritization input and accountability for payment scope that affects public money handling. Moving the entire epic into the risk register and stopping refinement fails because size is a backlog-structuring problem, not a risk-register destination that ends analysis. Converting the epic into a single nonnegotiable predictive milestone with no further breakdown fails because it abandons adaptive decomposition and recreates big-bang delivery risk for payments.
Exam caveat: Large epics are refined by splitting into ordered, valuable stories—not by hiding, rebranding as risks, or freezing as one milestone. Operational check: split “payments” into independently valuable stories such as card pay, confirmation, and failure handling; order them with the product owner; and pull only what fits the next iteration while keeping remaining slices visible on the billing backlog.