How does a team forecast work for a Sprint?

WHAT THIS TESTS: This question tests your understanding of accountability and empiricism within Scrum. The interviewer is listening for one key thing: do you know that the Developers (the people doing the work) are solely responsible for selecting the amount of work for a Sprint? It also reveals if you grasp that this is a forecast based on data, not a commitment dictated by management.

A GOOD ANSWER COVERS: A strong answer explains that the Developers select work based on several inputs. First, the Product Backlog, which is ordered by the Product Owner, provides the list of available options. Second, the team's past performance; this is the empirical part, often represented by average velocity or throughput from previous Sprints. Third, their capacity for the upcoming Sprint; this accounts for vacations, holidays, or other events that reduce availability. Fourth, the current Definition of Done; a more rigorous DoD means each item requires more effort, reducing the amount of work they can forecast.

COMMON WRONG ANSWERS: The most common mistake is saying the Product Owner or Scrum Master tells the team how much work to take on. The PO owns the 'what' (the priority), but the Developers own the 'how much'. Another red flag is using the word 'commitment' to describe the Sprint Backlog items. The team commits to the Sprint Goal, while the backlog is a forecast of the work needed to achieve it. Finally, treating velocity as a rigid target (e.g., 'Our velocity is 30, so we take exactly 30 points') is a junior-level mistake. It's a guide for a conversation, not a rule.

LIKELY FOLLOW-UPS: Expect questions like, 'What do you do if a team consistently pulls in too much work and fails to deliver?' (The answer involves using the Sprint Retrospective to inspect the cause, such as story slicing, estimation accuracy, or external impediments). Another follow-up is, 'How do you forecast for a brand new team with no historical data?' (Answer: Make an educated best guess for Sprint 1, and then use the actual results to inform the forecast for Sprint 2. Empiricism starts on day one.)

ONE CONCRETE EXAMPLE: A team's average velocity over the last three 2-week sprints is 40 points. In the upcoming sprint, one of five developers is on vacation for a week. The team might reduce their forecast capacity by roughly 10% (1 developer out for half the sprint = 1/5 * 1/2 = 10%). They would use about 36 points as a starting point for their planning discussion. They then pull items from the top of the backlog, discuss the complexity, and select a final set of items they believe they can complete to achieve the Sprint Goal.