Forecasting Through Epic Uncertainty

Every Epic begins as a question mark. Someone has a big idea, a strategic bet, or a customer commitment, and the rest of us are left trying to answer the only question that ever really matters: when will this be done?

The trouble is that Epics are uncertain by nature. They start fuzzy, get clearer as we break them down, and then promptly get fuzzy again the moment work begins and reality starts pushing back. Trying to forecast an Epic with a single guess at a single point in time is like managing your personal finances once a quarter without adjustments for things like rising gas prices or fluctuating egg costs.

There are three of those moments in the life of an Epic where forecasting genuinely earns its keep. Each one uses different inputs, answers a different question, and protects you from a different kind of bad surprise.

Phase One: The Epic Has No Child Items Yet

At the very beginning of an Epic's life, you almost never have what traditional estimation wants you to have. There are no stories. There are no tasks. There might not even be a clean problem statement. Someone has named a thing and pointed at it, and now leadership wants a date.

This is the moment where most teams either refuse to forecast at all ("we can't possibly know yet") or pull a date out of thin air that haunts them for the next six months. Both responses are bad. The first leaves the business flying blind on something it needs to plan around. The second anchors everyone to a fantasy (and misery).

There is a better approach. Look at your past Epics. Count how many child items each one ended up containing once it was actually done. Sort those counts and find the 85th percentile. That number, the 85th percentile of historical Epic size, becomes your starting budget. It says, with reasonable confidence, "Epics around tend to be larger than this only 15% of the time." Pair that child item budget with your team's historical cycle time, and you can produce a baseline completion date.

This is not a commitment. It is a calibrated guess that uses the only evidence available, the actual size of work your organization has shipped before. It gives stakeholders a date they can plan around, and it gives the team a budget they can design against. If breakdown starts producing scope that blows through that 85th percentile child item budget, that itself is a signal worth surfacing early that your cycle time is likely at risk too.

Phase Two: The Epic Is Defined and Ready to Start

Eventually the Epic gets broken down. You can count the child items. You know, at least at this moment, the shape of the work. Now you can do something more precise than referencing past Epic sizes. Now you can forecast the actual Epic in front of you.

This is where Monte Carlo earns its place. Take your team's historical throughput, the daily or weekly count of child items completed, and run thousands of simulated futures. In each simulation, the team works at a randomly sampled historical pace day after day until the known number of child items is finished. Some simulations finish fast. Some finish painfully slow. Most cluster in the middle.

Sort all those simulated completion dates and pick the 85th percentile. That is the date by which, given how this team has actually performed, you would expect to be done in roughly 85 out of 100 possible futures. It is honest about variability. It is generous enough to absorb normal bad days without being so padded that it stops being useful. It is the date and likelhood you can share with stakeholders.

The advantage of this approach over the baseline date from Phase One is that it uses real, specific information about this Epic, the known number of child items, alongside the team's real, specific throughput history. The forecast tightens. The conversation with stakeholders gets more grounded. You are no longer reasoning by analogy to past Epics. You are reasoning from the work in front of you.

Phase Three: Continuously Reforecasting Once the Work Has Started

Here is the part teams skip, and it is the part that matters most.

The date you forecasted at the end of Phase Two was true on the day you forecasted it. It will not stay true. Scope will move. Pace will move. The number of Epics the team is juggling at any given time will move. Every one of those movements changes the probability of hitting the date you committed to, and most of them happen quietly, without anyone noticing until the math has already gone sideways.

Reforecasting is the discipline of running the Monte Carlo again, often, and watching how the likelihood of hitting the date changes in response to the real conditions of the work.

• More often than not, Epic scope grows. New child items appear because something you thought was one thing turned out to be three. The forecast slides right. Catch it early and you can negotiate. Catch it late and you are apologizing.
• Your team’s delivery rate will change. People go on leave, a dependency lands, a key person comes back, a new tool starts paying off. Throughput shifts, and the forecast shifts with it.
• Epic WIP changes. The team gets pulled into a second or third Epic, or finally finishes one and focuses down. The amount of attention this Epic is actually getting changes the rate at which child items close, and the forecast reflects that.

The point of reforecasting is not to chase precision. It is to make delivery risk visible while there is still time to do something about it. Every time the 85th percentile date drifts away from the date you committed to, you have a decision to make: cut scope, add capacity, reduce WIP, or change the commitment. Reforecasting is what makes that decision a choice instead of a surprise.

Why All Three Phases Matter

It is tempting to pick one approach to forecasting and consider the others optional but delivery risk is hiding in each of these phases. 

Phase One protects you from the risk of committing to scope you cannot afford. Before a single child item exists, the 85th percentile of historical Epic size tells you what a realistic budget looks like and gives the business something to plan against. Without it, you say yes to things you should have pushed back on.

Phase Two protects you from the risk of committing to a date that does not match the actual work. Once the Epic is broken down, Monte Carlo on real throughput against real child item counts replaces analogy with evidence. Without it, you are still guessing, just with more confidence than the guess deserves.

Phase Three protects you from the risk of being wrong quietly. The forecast you made at the start of the work is a snapshot. Reality keeps moving. Without continuous reforecasting, you only find out you are going to miss when you actually miss, and by then your options are mostly bad ones.

Taken together, the three phases form a single practice rather than three separate ones. The first phase sets an honest expectation when there is almost nothing to go on. The second phase replaces that expectation with a sharper, evidence-based commitment the moment the work is knowable. The third phase keeps that commitment honest as conditions change. Each phase answers a different question, but they all answer the same underlying one: what is our delivery risk right now, and what should we do about it?

Forecasting through Epic uncertainty is not about predicting the future. It is about refusing to be surprised by it.

‍