Forecasting in SAFe Without Story Point Theater

The issue is usually not story points themselves. The issue is what people start doing around them.

Teams start optimizing for point alignment instead of slicing work well. Features get assigned precise-looking numbers long before anyone understands the real dependencies. PI plans and roadmaps inherit that fake precision. By the time delivery starts slipping, everyone argues about commitment quality instead of looking at flow.

If this sounds familiar, the fix is usually not “estimate harder”. It is to reduce the batch size, improve the flow, and forecast using evidence.

The basic idea is borrowed from the #NoEstimates world: instead of trying to size every story precisely, slice the work into chunks that are small enough to understand, finish, and learn from quickly.

One simple way to think about it is replacing classic planning poker cards with something closer to 1, Too Frighteningly Big, and No Faintest Clue.

That changes the conversation in a useful way:

• If it is a 1, it is small enough to flow.
• If it is too big, slice it.
• If nobody has a clue, stop pretending the number will save you and go learn more.

This has a few practical benefits in SAFe:

• PI Planning gets faster.
• Teams are pushed toward smaller, more comparable stories.
• Cross-team alignment gets easier because “small enough to finish quickly” is easier to calibrate than abstract point scales.
• Iteration forecasting becomes more about actual throughput and less about estimation rituals.

For team-level forecasting, what matters most is whether your stories are small and reasonably comparable. Once they are, historical throughput becomes very useful.

If a team typically finishes about 18 to 22 similarly sliced stories in an iteration, that tells you a lot. If the team already has aging carry-over work or a board full of stuck items, that tells you a lot too. You don’t need another round of point debates to learn that.

A practical SAFe forecasting pattern looks like this:

1. Slice stories small enough that counts start to mean something.
2. Look at historical throughput for similar work.
3. Check current WIP and work item age so you don’t forecast on top of hidden congestion.
4. Create a range-based forecast, not a single deterministic promise.

That is a much healthier way to plan a PI than pretending a stack of feature points somehow made the uncertainty go away.

This is where the conversation gets more interesting.

If you want to answer questions like “What is likely to finish this PI?”, “Can we release this capability by Q3?”, or “How much of this roadmap is realistic?”, the most useful metrics are usually throughput, cycle time, work item age, and WIP.

Throughput tells you how many items you actually finish in a given period. For release or roadmap forecasting, this is your volume signal.

Cycle time tells you how long similar items usually take once they start. For release forecasting, this is your elapsed-time signal.

Work item age tells you whether started work is flowing normally or is already in trouble.

WIP tells you whether your system is stable enough for any forecast to mean much in the first place.

For roadmap and release forecasting in SAFe, I usually like this logic:

• Use story counts or similarly sized slices as the planning unit where possible.
• Use throughput history to forecast how much is likely to get done in a time window.
• Use cycle-time history to understand how long started work tends to take.
• Use work item age and dependency visibility to challenge optimistic assumptions.

If you want a more probabilistic answer, this is where Monte Carlo style forecasting becomes much more useful than another round of point normalization. I unpack the metric side of this in Improving your SAFe implementation with some additional flow metrics and in Flow Metrics for Scrum: WIP, Cycle Time, Throughput, and Work Item Age.

I am not dogmatic about “no estimates”.

At the story level, explicit sizing often creates more overhead than insight. At the feature, capability, or epic level, some lighter relative estimation can still be useful, especially when you need to make economic decisions or discuss dependencies across teams.

What I often do in these situations is use story counts as the higher-level currency.

So instead of saying “this looks like a 20-point feature”, we say “this looks like roughly 20 small stories when we eventually slice it.” We are still estimating. We are just estimating in a way that is easier to connect to actual flow later on.

This also helps with PI and roadmap forecasting. If a feature looks like about 20 stories, and we already identified 7 for the first iteration and 4 for the second, we can reason about the remaining scope without pretending we already know every detail.

And if there are dragons hiding in the remaining chunk, usually dependencies, integration risk, or external coordination, that is the moment to surface them. Not bury them inside an impressive-looking estimate.

The approach works well when people keep it honest. It gets messy when they don’t.

One mistake is counting stories without improving slicing discipline. If your “stories” range from half a day to three weeks, throughput will be noisy and people will conclude flow metrics do not work.

Another mistake is treating forecasts as commitments. Throughput and cycle time help you forecast probabilities. They do not create guarantees.

A third mistake is ignoring dependencies. If a feature crosses too many teams, the problem is not the lack of a better estimate. The problem is your delivery design.

Yes, you can forecast in SAFe without making story points the center of the universe.

At the team level, smaller stories plus throughput often beat heavy estimation rituals. At the release and roadmap level, flow metrics give you a much better way to answer “what is likely by when?” than point totals ever did.

If you still need some estimation at the feature or capability level, fine. Just keep it light, keep it honest, and connect it to real flow instead of wishful thinking.

Can you do PI Planning in SAFe without story points?

Yes. Teams still need a way to discuss scope, risk, and sequencing, but that does not mean every conversation needs to revolve around point totals. If stories are sliced small and consistently enough, story counts plus historical throughput can be enough for team-level planning.

Is throughput better than velocity for SAFe forecasting?

Often yes, especially when the team has disciplined slicing. Throughput is based on completed work, not on how people calibrated their estimates. If item size varies wildly, throughput alone is not enough, but it is usually still a more grounded signal than velocity theater.

How do you use cycle time for release forecasting in SAFe?

Use cycle time to understand how long similar items usually take once they start moving through the workflow. It is especially useful for setting expectations about elapsed time and for spotting whether your release forecast assumes smoother flow than you usually get.

Should we stop estimating features and capabilities entirely?

Not necessarily. I usually reduce or remove detailed story sizing first. At higher levels, lighter relative estimation or story-count ranges can still help with economic sequencing, dependency conversations, and roadmap tradeoff discussions.

What is the biggest trap when using flow metrics for roadmap forecasting?

Using unstable data. If work item sizes are inconsistent, WIP is out of control, or dependencies dominate the system, your forecast will still be noisy. Flow metrics do not magically fix the system. They make the system easier to see.

If you’re trying to get your SAFe planning out of the compliance-theater zone, take a look at my SAFe advisory work or reach out.