How is work selected and forecasted for the Sprint Backlog?

What's really being asked

This question tests whether you understand empirical forecasting as defined in the Scrum framework. The interviewer wants to see if you know that Scrum relies on empiricism, where decisions about how much work to select are based on experience and observation rather than on formulas or external mandates. They are also checking if you recognize the division of accountability: the Product Owner orders the backlog, while the Scrum Team who collectively possess the needed skills decides how much work they can turn into a valuable Increment during the Sprint.

A GOOD ANSWER COVERS four things in order. First, the Product Owner orders the work into a Product Backlog, which serves as the input list. Second, the Scrum Team uses empiricism, meaning they apply knowledge gained from past experience and make decisions based on what they have observed about their own capability and the complexity of the work. Third, the Scrum Team selects a specific selection of work that they forecast they can transform into a single Increment of value during the Sprint. Fourth, the team understands that this forecast is not a fixed contract but an empirical projection that is inspected and adapted throughout the Sprint events.

The mistakes people make

Treating the Sprint forecast as a hard commitment or guarantee is a major red flag because Scrum is empirical and adapts to emerging reality. Citing velocity, story points, or capacity hours as defined Scrum Guide inputs is also wrong since the provided framework text does not prescribe those tactics. Another red flag is saying the Product Owner or a manager alone decides how much work is taken on; the text indicates the Scrum Team turns a selection of work into the Increment, reflecting a team decision based on collective expertise.

What usually comes next

An interviewer might ask how the team handles the forecast when unexpected complexity arises, which should lead to a discussion of inspection and adaptation within the Sprint. They might also ask how the Product Backlog order influences the selection, or what happens if the team cannot finish the forecasted work.

A concrete example

Suppose a Scrum Team has observed over several Sprints that they can reliably turn the top ordered items into a valuable Increment when those items require roughly similar collaborative effort. During Sprint Planning, the Product Owner presents the ordered Product Backlog. The Scrum Team discusses what they have observed about their recent delivery capability and their collective expertise. Based on that empirical evidence, they select a slice of the top ordered items they forecast they can complete. They do not treat the selection as a guaranteed promise; instead, they plan to inspect progress daily and adapt their plan if what they observe during the Sprint differs from their forecast.