A Definition of Ready checklist for the public-works inspection app now requires signed UX comps, a legal memo, and a cost-benefit PDF before any item may enter Sprint Planning. Work has stalled. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Ready should be a light backpack, not a locked vault. If inspectors cannot start until Legal, UX, and Finance all stamp a PDF, you have reinvented waterfall and called it Scrum. Pack just enough so the next Sprint can move—then learn the rest on the job.
Full Explanation
Definition of Ready should help forecasting, not recreate waterfall gates. When a public-works inspection app checklist requires signed UX comps, a legal memo, and a cost-benefit PDF before any item may enter Sprint Planning and work has stalled, the Product Owner should keep lightweight readiness that clarifies near-term intent without maximal upfront documentation. Adding more checklist rows until every risk is documented in advance deepens the stall. Treating the checklist as a contract where failing any row permanently defers items punishes learning. Moving all not-Ready items to a PMO stage-gate so Scrum starts only after design is finished abandons empiricism. Exam caveat: some inspection workflows need legal or safety clarity earlier than others, but Ready remains a team-helpful agreement—not an external approval bureaucracy. Operational check: strip Ready to what Developers need to forecast, allow refinement to close remaining gaps, start Sprint Planning on ready-enough inspection items, and refuse PMO stage-gates as a substitute for Product Backlog accountability. Ready-enough for public-works forecasting is a team agreement refreshed by learning, not a permanent PDF gate before every Sprint.