How would you create a probabilistic forecast for a backlog?

What's really being asked

This question assesses your ability to move beyond simple, deterministic planning (like using average velocity) and apply statistical methods to create a more realistic, risk-aware forecast. It tests your understanding of flow metrics (specifically throughput), variability, and how to communicate uncertainty to stakeholders using probabilistic language. The interviewer is looking for a senior engineer who can provide data-driven, nuanced answers about delivery timelines, not just a single, likely-to-be-wrong date.

The full answer

A strong answer outlines a four-step process. First, gather the raw data: the team's historical throughput, which is the number of stories completed per week for the last 10-20 weeks. Second, explain the simulation method: you'll use a Monte Carlo simulation. This involves running thousands of simulated "futures" (e.g., 10,000 trials). In each trial, you randomly sample from your historical weekly throughput data, adding up the completed stories week by week until the 40-story backlog is cleared. The number of weeks it took is recorded for that trial. Third, describe how you interpret the results. After all trials are run, you sort the completion dates and present them as a probability distribution. For example, you find the date by which 50% of simulations finished (50th percentile), 85% finished (85th percentile), and 95% finished (95th percentile). Fourth, explain how you communicate this to the PM. You'd say: "There's a 50% chance we'll finish in 8 weeks, an 85% chance we'll finish by 10 weeks, and a 95% chance we'll finish by 12 weeks." This frames the conversation around risk and confidence, not certainty.

The mistakes people make

The most common mistake is using an average. For example, calculating the average weekly throughput (e.g., 5 stories/week) and dividing the backlog size by it (40 stories / 5 per week = 8 weeks). This is a deterministic, single-point estimate that ignores the reality of variation and is statistically flawed due to the "flaw of averages". Another red flag is confusing throughput (count of items) with velocity (sum of story points). This question specifically mentions "similarly-sized stories," which is a cue to use throughput. A less severe error is describing the concept vaguely without mentioning the specific mechanism of Monte Carlo simulation or the use of percentiles to communicate the results.

What usually comes next

Expect questions like: "What if the stories aren't similarly sized?" (Answer: Use story points and velocity, but the Monte Carlo simulation technique is the same, just sampling from historical velocity data). "How much historical data is enough?" (Answer: Ideally 10-20 data points, e.g., 10-20 weeks of throughput. Less than 8-10 is risky as it may not capture true variability). "What if the team composition changes?" (Answer: Acknowledge that the historical data is no longer representative. You'd need to gather new data for a few sprints before you can forecast reliably again, or state the forecast has very low confidence).

A concrete example

Let's say our team's throughput for the last 10 weeks was: 3, 5, 4, 6, 2, 5, 4, 3, 5, 7 stories per week. To forecast a 40-story backlog, we run a simulation. Trial 1 might randomly pick weeks with throughputs of 5, 2, 7, 4, 5, 3, 6, 4 (sum=36), 5 (sum=41). That took 9 weeks. Trial 2 might pick 3, 3, 4, 5, 2, 7, 5, 4, 3, 5 (sum=41). That took 10 weeks. We repeat this 10,000 times. If the 8,500th fastest result is 10 weeks, we can state with 85% confidence that the work will be done by the end of week 10.