Stakeholders for a municipal transit app demand a Gantt chart of every feature for the next twelve months. How should the Product Owner respond?
Select an answer to reveal the explanation.
Short Explanation
A year-long feature Gantt is a frozen menu, and rider needs will not sit still that long. Keep the Product Goal as the destination and a near-term forecast as the next few stops. Far-out bars dressed up as commitments just pretend the city already knows next winter's surprises.
Full Explanation
For a municipal transit Product Owner, forecasting means steering toward a Product Goal with a near-term empirical outlook, not publishing a contractual schedule of every rider-facing feature for the next twelve months. Declining a frozen long-range feature Gantt while still offering a Product Goal and an inspectable near-term forecast preserves transparency without pretending next winter's ridership surprises are already known. Producing the year-long Gantt and treating each bar as a Sprint commitment replaces inspection with fake precision and makes adaptation politically expensive when rider needs shift. Refusing any outlook beyond the current Sprint is unnecessary secrecy; Scrum does not forbid talking about future work, it forbids treating unvalidated far-horizon features as Done commitments. Handing the Gantt request to the Scrum Master so the Product Owner can focus on writing user stories abdicates Product Owner accountability for ordering and forecasting value. Exam caveat: stakeholders still deserve a transparent outlook—advanced Product Ownership refuses frozen feature contracts, not communication. Operational check: show the Product Goal, the ordered near-term backlog slice, and the confidence assumptions behind the next few releases; label anything beyond that horizon as themes or hypotheses, not dated Sprint commitments.