Home › Forecasting Jira without story points

Guide

How to forecast Jira releases without story points

Someone asks when the release will be done. You could add up the story points and divide by velocity. Or you could count what the team really finished over the last weeks and let a Monte Carlo simulation give you dates with their odds. This guide walks through the second way, and says where it falls short as it goes.

By LetPeopleWork, the makers of Lighthouse · Updated 17 October 2026

Why story points make a weak forecast

Story points were meant to start a conversation about a piece of work. As an input for a forecast they cause trouble. When Peter plotted his teams' story points against how long the items really took, he found almost no relationship: items estimated at 2 points took anywhere from a few days to almost 160 days (Reality check through scatter plotting).

Estimates are noisy as well. Two teams estimating similar features can land far apart, and once teams get compared on their numbers, a 5 has a way of turning into an 8 (The hidden cost of noise, Why you should compare metrics of different teams). Divide one noisy number by another and you get a date that looks precise.

If your team finds points useful for talking through a piece of work, keep them for that. You don't need them to forecast.

What you need instead: finished items and their dates

Throughput is the number of items your team finishes per day. Jira already records it, because every issue that reaches Done has a date. There is no extra field to fill in and no estimation meeting. Each item counts as one, whatever its size. That sounds crude, and it works well enough as long as items are kept reasonably small (more on that further down).

Holidays and sick days are already in that history, so you don't have to plan capacity on top of it.

How a Monte Carlo forecast works

Take the last 30 days and how many items the team finished on each of them. To forecast, the simulation builds one possible future: for every day ahead it picks one of those past days at random and uses its count. It keeps adding until the remaining items are done, or until the target date is reached. Then it builds the next future. Lighthouse does this 10,000 times, and the share of futures that make it is your probability.

That gives you two kinds of answers:

• When will these items be done? You get dates with their odds, for example 50% by one date and 85% by a later one.
• How many items will be done by a date? You get counts with their odds.

Benji's step-by-step guide to Monte Carlo simulations builds the same thing in a spreadsheet, if you want to see every step.

Which date to promise

The 50% date is a coin flip: half of the simulated futures finish later. That's fine for planning inside the team. For a customer or a steering committee, Peter's advice is short: use the 85% date and sleep well. When missing would be expensive, use 95%.

An 85% date still misses roughly one time in seven. Say so when you share it. A range with its odds makes for a better conversation than a single date that everyone suspects is a guess (Dear stakeholder, here's why I'm giving you a range).

Does it hold up? Check it against your own past

Benji compared both methods on a real team with six developers. Their average from the previous month said 37.5 items in the next 30 days. The Monte Carlo forecast said 38 items at 50%, 35 at 70%, 31 at 85% and 27 at 95%. The team finished 30, one fewer than the 85% forecast and well short of what the average promised (The flaw of averages).

When Peter backtested his own team, the 85% forecast said 12 items for two weeks. They finished 16 (How Lighthouse changed the way I work).

You can run the same check on your data. Lighthouse's Forecast Reality Check forecasts weeks that already happened, as if they hadn't, and compares the result with what the team really finished, for each percentile and history window.

What about items of very different sizes?

Counting items doesn't need them all to be the same size. It needs them small enough that one giant ticket can't swallow a month. The common way to get there is a service level expectation (SLE): the team agrees that 85% of its items should be done within, say, 10 days. Before anyone starts an item, the team asks one question. Can we finish this within our SLE? If not, split it first.

Sizing Poker asks that question for a whole backlog in a few minutes, in the browser and for free.

Epics that have no child items yet get a size from your history. Lighthouse can assume, for example, as many items as 85% of your past features needed. In Benji's own team, 85% of features had 7 child items or fewer (Low WIP, small features, high freedom).

Where it falls short

• It assumes the next weeks look roughly like the last ones. A reorganisation, a new team or a holiday season changes that. Pick a history window that resembles what's coming: a team that formed a month ago shouldn't use three months of history.
• It can't see work that doesn't exist yet. In one case study a release grew from 29 items to 63, with 34 added along the way, 26 of them bugs. Forecasting the original 29 said 9 April, and the release shipped on 25 April. Re-run with all 63 items, the 85% forecast said 26 April. So re-forecast whenever the scope moves (Monte Carlo simulations, accuracy and unplanned work).
• Several teams on one feature lower the odds. All of them have to make it. Five teams that are each 85% sure give you a joint date that is close to a coin flip (Forecasting across several teams).
• Spiky throughput gives wide ranges. That's useful information in its own right: predictability is something a team can work on.

What Jira does on its own

Jira Plans, part of Jira Premium and Enterprise on Cloud and called Advanced Roadmaps on Data Center, schedules work from estimates, team capacity and velocity, in story points or hours. Items without an estimate are left out of the capacity (capacity and velocity in Plans). The velocity chart can count issues instead of points, and the control chart shows cycle time with an average. A forecast with its odds isn't part of Jira, as far as Atlassian's documentation shows. Marketplace apps such as ActionableAgile add Monte Carlo charts inside Jira. Lighthouse does it from outside, on your own systems (how they compare).

Doing it in Jira with Lighthouse

A spreadsheet is fine for a one-off forecast. Lighthouse keeps forecasting against your Jira as items finish:

1. Install Lighthouse on your laptop or a server, as a desktop app, a Docker container or on Kubernetes.
2. Connect Jira. Jira Cloud uses your username and an API token. Jira Server and Data Center, version 8 or later, use a personal access token, so a Jira that is only reachable inside your network works as well.
3. Add a team with a JQL query, for example project = "SHOP" AND labels = "checkout". Then say which issue types count and which states mean doing and done.
4. Ask when a set of items will be done, or how many will be done by a date. Epics are forecast too, including epics that several teams work on.

Lighthouse doesn't use story points for its forecasts. If you keep estimating anyway, it can show how your estimates compare with how long items really took. On paid editions it can also write the 85% date back into a Jira field, so people see it where they already look.

About two weeks of finished work is usually enough for a first forecast. The documentation explains how Lighthouse forecasts in more detail.