A "rebuild online permitting" epic is so large that neither Developers nor stakeholders can forecast the next valuable release. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A boulder does not go through the door. You cut it into stones that still do something useful—submit one permit type, show one status—then you can actually forecast. Giant rebuild-everything epics just sit there looking important.
Full Explanation
Large items block forecasting and delay feedback. When a rebuild-online-permitting epic is so large that neither Developers nor stakeholders can forecast the next valuable release, the Product Owner should slice it into thinner Product Backlog items that can each deliver an inspectable outcome—for example one permit type end-to-end—rather than architectural inventory. Keeping the epic intact so the city can announce a single big go-live date hides uncertainty instead of reducing it through increments. Replacing slicing with a two-year Gantt assigned by Finance substitutes a plan document for empiricism. Splitting the epic by architectural layer—UI, API, and database—and calling each layer a Product Goal often produces unreleasable work and misuses the Product Goal concept. Exam caveat: some enabling work is sometimes necessary, but vertical slices that yield usable citizen or clerk outcomes are the default teaching answer for PSPO II forecasting questions. Operational check: rewrite the epic into outcome-oriented items, refine the top slices to ready-enough, forecast a Sprint Goal around one inspectable permitting outcome, and review evidence with public-works stakeholders before committing the next slice.