“When Will It Be Done?”: Not One Date, a Range of Probabilities

From the field: where did 27 March come from?

That morning in the corridor, I did the calculation in my head. The account opening flow was split into 41 items, 196 points in total. The last sprint’s velocity was 34, but it was going up. I said to myself, “40 is fine.” 196 divided by 40 is 4.9 sprints. I rounded up to five sprints. If we started on 19 January, the fifth sprint would end on Friday 27 March. I added no buffer, because velocity was rising.

This calculation had three assumptions that I did not say out loud. Later, I put each one next to what really happened:

The first row hurts the most. My velocity assumption was right, but it did not help. Velocity counted all of the team’s points, not this project’s points. I explained where the points came from in the cycle time post: internal items were short and clear, and they got finished while customer work waited. I had also explained what breaks when you turn points into dates, in the story points post. I wrote that post in November, and I made the same mistake myself.

On 27 March, 31 of 47 items were done. The remaining 16 items took four more weeks. The last one was done on 24 April, and with the release train and operations acceptance we went live on 5 May. When and how I reported the risk is a separate topic. This post is about the date itself: how I produced it.

Why does one date not work?

The finish date of software work is not one point. It is a distribution. Some weeks 2 items finish, some weeks 6. Some items close in one day, some wait three weeks for acceptance. When you squeeze this uncertainty into one date, you do one of two things. You pick a very optimistic point, or you add a hidden buffer. In both cases, the other person does not know how much risk they are taking.

The most common mistake is to use the average. “We finish 3.8 items per week on average. There are 42 items, so 11 weeks.” This calculation gives you a date with about 50% probability. In other words, a coin toss. Below, I will show this with our own data.

One note: inside a sprint, this problem does not exist. In sprint planning, you make a two-week commitment, and velocity is enough for that question. The problem starts when you stretch the same arithmetic to ten weeks of work. Small differences that look harmless in two weeks add up over ten weeks. One date shows none of them.

Count items, not points: throughput

Monte Carlo needs only one piece of data: in each of the last few weeks, how many items finished? A count, not points. There are two reasons. First, a count needs no estimate. The number of items that reached “Done” in Jira is not open to debate. Second, if you split work into similar sizes, the variation in the count gets smaller. In our team, most items take two to five person-days. Whether an item is 5 or 8 points hardly changes the result of the forecast.

One distinction matters. If you ask when one item will be done, the answer is the cycle time p85: “85% of the items we start finish within 10 days.” If you ask when many items, a whole project, will be done, cycle time is not enough. Items move in parallel, not one after another. There, you need throughput and a simulation.

Monte Carlo: a 20-line calculation

In early April, the next project arrived: the card application flow, 36 items. This time I did not answer in the corridor. I said, “I will bring two numbers on Friday.” For scope growth, I used the rate from the first project: 36 × 1.15 = 41.4, rounded up to 42 items. Then I ran this calculation:

import random

history = [3, 5, 2, 4, 6, 3, 4, 5, 2, 4]  # last 10 weeks: items finished each week
remaining = 42                             # 36 items + 15% scope growth buffer
trials = 10000

results = []
for _ in range(trials):
    done, weeks = 0, 0
    while done < remaining:
        done += random.choice(history)     # pick a random past week
        weeks += 1
    results.append(weeks)                 # how many weeks this trial took

results.sort()
for p in (50, 85, 95):
    print(p, results[int(p / 100 * trials) - 1])

# output:
# 50 11
# 85 13
# 95 13

The logic is simple. We assume each future week will look like one of the past weeks, but we do not know which one. So we pick one at random and count until the work is done. When you do this ten thousand times, you do not have one answer to “how many weeks?”. You have ten thousand answers. Then you sort them and read them. The project would start on Monday 27 April, after the last items of the account opening flow. When we turned weeks into dates, the table looked like this:

With the average, I would have said: 42 / 3.8 = 11.05, so 11 weeks, 10 July. In the table, that is 53%. I was about to repeat my January mistake with cleaner arithmetic.

Three objections from the team

When I first showed the calculation to the team, three questions came up. All three were fair, and the answers also show the limits of the model.

“Isn’t 10 weeks too little?”

This was Mehmet’s question. It is little, but not as little as you think. In the history, the worst week is 2 and the best week is 6. Next week could fall outside this range, but it is not likely. If you use a longer history, you also bring the old team and the old process into the model. We use the last 10 weeks. Every week, we drop the oldest week and add the newest. When the team changes a lot, for example when someone leaves, we drop all data from before that week.

“Why 10,000 trials?”

The number is not magic. With 1,000 trials, the results could move by a week from one run to the next. With 10,000 trials, they did not. The calculation takes less than a second, so we did not bother with fewer trials. The number of trials is less important than the quality of the input. A million trials with wrong throughput data also give a wrong range. It just looks more precise.

“But items are not the same size?”

This was Ayşe’s question, and the most important one. They are not the same size, but the items in past weeks were not the same size either. The model assumes future items come in a similar mix to past items. This holds as long as you split work in a similar way in refinement. In the first list of the card project, two items looked longer than a week. We split them before starting. 36 is the number after splitting.

How did I explain the range to management?

My first attempt was bad. On Friday 10 April, I showed the deputy general manager the four-row table above and a histogram. Five minutes later I heard: “OK, let’s say 3 July.” The first row of the table, the date with an 18% chance, had become a promise in his eyes. The tallest bar in the histogram was week 11, and he read “the tallest bar” as “the most likely date”. Both were my mistakes: too many numbers and a chart without explanation.

One week later, I brought the same information on a single card:

The question changed. He asked, “Which date should I give?” I said, “If you make a promise outside, use 85%. Inside, let’s plan for 50%. If we slip, there are two weeks in between.” Outside, the date was 24 July. Inside, the target became 10 July.

The real gain was the “every Monday” line. A single date is said once, and after that everyone defends it. A range is calculated again every week with new data. If the date is slipping, you see it weeks earlier, not in the last week, and there is still time to decide.

Today: 31 May

Five weeks have passed. 17 items are done, 3.4 per week. That is below the 3.8 the model assumed; internal work took more space than I expected. Scope grew from 36 to 38. 21 items remain, or 24 with the 15% buffer. This morning I ran the calculation again:

The 50% date moved by one week. The chance of the internal target, 10 July, dropped to 41%. Tomorrow morning I will tell the deputy general manager myself, before he asks. But the 24 July date we gave outside is still safe; the chance of finishing by then is 98%. In January, I had this conversation after 27 March had passed. This time, I am having it six weeks before the target date.

How it breaks

Checklist

Conclusion

When I said “27 March” in the corridor on 12 January, I did not give a wrong date. I gave the wrong kind of answer. The other person asked about a probability. I gave him a promise, and I hid its probability, even from myself.

Today my answer to the same question is two dates and a day: “50% by this one, 85% by that one, I will update it on Monday.” It is a longer answer, but it creates fewer meetings. One date gives comfort. A range earns trust.