How do you provide a probabilistic forecast for completing 25 stories?

WHAT THIS TESTS: This question tests your maturity as an engineer and planner. It's not about the math of Monte Carlo, but your ability to move beyond deterministic, single-date promises (which are always wrong) to probabilistic forecasting. It assesses whether you understand how to use a team's actual, demonstrated performance (flow metrics) to model future outcomes, manage stakeholder expectations, and communicate uncertainty and risk in a professional way.

A GOOD ANSWER COVERS: A strong answer walks through a clear, four-step process. First, gather the raw data: the historical cycle times for a significant number of the team's recently completed stories, perhaps the last 50-100. It's crucial to use cycle time (start to finish time), not story points. Second, explain the simulation: for a single trial, you randomly sample 25 cycle times from your historical data and sum them to get a total duration. Third, describe iterating: you repeat this simulation thousands of times (e.g., 10,000 or more) to generate a distribution of possible total durations. Fourth, explain how you communicate the results: you create a histogram from the simulation outcomes and use percentiles to provide a forecast, such as, "There is an 85% probability we will complete this batch of work in 42 days or less."

COMMON WRONG ANSWERS: The most common red flag is using story points. Story points are a unit of relative effort, not time, and are useless for forecasting duration. Another mistake is using the average cycle time multiplied by 25. Averages hide the risk in the long tail of the distribution; real-world cycle times are not normally distributed. A weak answer also gets bogged down in statistical jargon instead of focusing on the practical application and communication with the product manager. Finally, simply saying "I'd use a tool" without explaining the underlying process shows a lack of deep understanding.

LIKELY FOLLOW-UPS: Expect questions like, "What if you don't have enough historical data?" A good response is to state that you'd start collecting it immediately, and in the short term, you could use rough estimates from the team to build a data set, but you would communicate the forecast has very low confidence. Another follow-up is, "How do you account for different story sizes?" The correct answer is that you don't need to. If your historical data includes a natural mix of sizes, the random sampling process automatically accounts for this variation.

ONE CONCRETE EXAMPLE: Let's say our team has the cycle times for its last 80 stories. To forecast the 25 new stories, we run 10,000 simulations. Each simulation randomly pulls 25 cycle times from our history of 80 and adds them up. After running all simulations, we get a distribution of outcomes. The results might show a 50th percentile (median) of 30 days, an 85th percentile of 42 days, and a 95th percentile of 55 days. You would tell the PM: "Our most likely outcome is around 30 days, but to be safe, there's an 85% chance we'll be done within 42 days. There's a 5% risk it could take longer than 55 days."