Towards the end of Sprint Planning, if the Developers cannot forecast Product Backlog items for the Sprint, which two approaches are best for the Product Owner?

• A. They discuss the upcoming Sprint Retrospective why this happened and what changes will make it less likely to occur again.
• B. The Developers forecast the most likely Product Backlog items and create a Sprint Backlog; Once time-box ends, they implement and continue to analyze and decompose.
• C. Both of the above
• D. Neither

Answer: (C)

When forecasting for a Sprint isn’t possible, you address it by combining learning from the past with practical forward progress. The Product Owner should use insights from the recent work to identify concrete changes that would make forecasting more reliable in the future—this means discussing what was learned in the previous Sprint and what adjustments will reduce the chance of this happening again. At the same time, it’s important to move forward with the best-possible forecast they can assemble, have the Developers create a Sprint Backlog around those items, and start delivering. As work progresses, the team continues to analyze, decompose, and refine the plan.

This dual approach keeps the process empirical: you adapt based on what happened previously and maintain momentum by starting with the most likely work and refining as you learn. If you only focused on retrospective discussion without enabling forward work, you’d delay value delivery and miss opportunities to learn from real progress. If you only tried to forecast and execute without addressing root causes from the past, the team might repeat the same issues. Using both together balances improvement with tangible progress, making it the best course of action.