Developers on a public-works inspection app warn that capacity will drop after a holiday period. Stakeholders still want the original political date. What should the Product Owner do?

Capacity-aware forecasting is a Product Owner accountability: when Developers on a public-works inspection app warn that capacity will drop after a holiday period, the release outlook must adjust downward to reflect realistic capacity instead of protecting a political date. Known constraints that are ignored become hidden risk that stakeholders discover as missed street inspections. Keeping the political date and asking Developers to skip the Definition of Done until after the holiday trades citizen-ready quality for calendar optics. Hiding the capacity warning so the date stays unchanged on the city website violates transparency. Adding a second Scrum Team immediately and keeping the same date without inspecting actual capacity assumes instant productivity that new teams rarely deliver and still avoids an honest forecast update. Exam caveat: stakeholders may still choose a date constraint, but then scope or quality trade-offs must be explicit—not silent overtime against Done. Operational check: quantify the post-holiday capacity change, reforecast the inspection-app Increment, and present the revised outlook with any scope thinning required to protect Done before the political date is reaffirmed.