The transit real-time-arrivals Product Owner wants more items in the Sprint than Developers forecast they can complete to Done. How should respect show up?
Select an answer to reveal the explanation.
Short Explanation
Ordering the menu is the Product Owner’s job; saying how many plates fit in the kitchen is the cooks’. Respect means not stuffing the Sprint after Developers already said what they can finish to Done. Keep ordering the backlog—just do not grab the capacity knob.
Full Explanation
The Product Owner is accountable for Product Backlog order and for maximizing value; Developers are accountable for creating a Done Increment and for their forecast of the work. Respecting that boundary on a transit real-time-arrivals product means the Product Owner keeps ordering the Product Backlog and respects the Developers' forecast of what they can complete toward the Sprint Goal—without overriding capacity to force extra items in.
Overriding the forecast and adding extra items so the Product Owner's order is also a capacity decision steals self-management and endangers Done. Letting the operations director assign overtime targets until the forecast matches desired scope reinstalls command-and-control. Replacing the Developers' forecast with last year's Gantt so capacity looks large enough substitutes an obsolete plan for team accountability.
Exam caveat: PSPO II respect items separate Product Backlog ordering from Sprint capacity forecasting; both accountabilities must remain intact.
Operational check: in Sprint Planning, confirm the ordered arrivals items and the Developers' forecast separately; if more value is needed than fits, re-order the Product Backlog for later Sprints rather than stuffing this Sprint.