During Sprint Planning, a Product Owner at a home-robot company pushes the app team to commit to eight Product Backlog items for the Sprint, more than the Developers believe is realistic. According to the Scrum Guide, who decides how many Product Backlog items the Developers forecast for the Sprint?
Select an answer to reveal the explanation.
Short Explanation
Forecasting Sprint work is like packing a backpack for a hike — only the people carrying it should decide how much fits. The Developers are the ones who select Product Backlog items and forecast what they can deliver, drawing on their own past performance and judgment. A Product Owner can advocate for more, but that decision stays with the people doing the work.
Full Explanation
The Scrum Guide places forecasting squarely with the Developers: they select Product Backlog items from the Product Backlog and forecast the functionality that will be part of the resulting Increment, informed by their capacity and their forecasting to date. The Product Owner's role in this conversation is to discuss the objective and clarify which items best serve the Sprint Goal, not to dictate a quantity of items the Developers must accept - pressure to take on more than the team believes is realistic conflicts with self-management by the people accountable for the work. Giving the Product Owner forecasting authority because the Product Backlog belongs to that accountability confuses backlog ownership with the separate decision of how much of it fits in a Sprint. Handing the decision to the Scrum Master misassigns a role that is about facilitation and coaching, not adjudicating scope disputes by fiat. Deferring to a project management office introduces an authority structure the Guide never describes; Scrum's accountabilities are limited to the Product Owner, the Scrum Master, and the Developers. Caveat: the Developers can renegotiate scope with the Product Owner as the Sprint progresses if new information emerges, but the initial forecast is theirs to set. Operational check: if a Sprint Planning session ends with a headcount the Developers didn't actually agree was achievable, the Scrum Master should treat that as an unresolved planning problem, not a finished plan.