How does a team forecast work for a Sprint?

WHAT THIS TESTS: This question tests your understanding of Scrum's core principle of empiricism as it applies to forecasting. The interviewer wants to see if you know that Sprint Planning is about the Developers making an informed forecast based on past data and current conditions, not receiving a work order. It's a test of whether you see the team as self-managing and empowered.

A GOOD ANSWER COVERS: A strong answer explains that the forecast is made by the Developers and is based on several key inputs. First, the Product Backlog, which is ordered by the Product Owner and provides the 'what.' Second, the team's past performance; knowledge gained from previous Sprints about how much work they typically complete. Third, the current capacity of the team, accounting for vacations, holidays, or team members' availability. Fourth, the overarching Sprint Goal, which provides focus. The Developers select Product Backlog Items and create a plan for how to deliver them.

COMMON WRONG ANSWERS: A major red flag is describing a top-down process. For example, saying 'The Product Owner gives us 40 story points of work' or 'Our manager tells us we need to complete these five tickets.' This shows a misunderstanding of the Developers' ownership. Another weak answer is focusing only on one metric, like velocity, without mentioning the other inputs like team capacity or the qualitative discussion required to assess complexity. Forgetting to mention the Sprint Goal as a focusing element is also a miss.

LIKELY FOLLOW-UPS: Be ready for 'What happens if the team consistently fails to meet its forecast?' (Answer: inspect and adapt in the Retrospective, look for root causes like poor estimation, external blockers, or unrealistic pressure). Another follow-up is 'How do you forecast for a brand new team with no past performance data?' (Answer: make an educated guess for the first 1-2 Sprints and then rely on the emerging empirical data).

ONE CONCRETE EXAMPLE: For a 2-week Sprint, a team of 5 developers might have a historical average velocity of 30 story points. During planning, they see one developer is on vacation for 3 days. They might adjust their capacity forecast down to 25 points. They review the top of the Product Backlog, discuss the items with the Product Owner to clarify the 'why,' and pull in roughly 25 points of work that align with the Sprint Goal. This becomes their Sprint Backlog.