Pacia Intelligence

For Product & Delivery Managers

Answer "is this shipping this quarter" without asking six people.

The forecast you currently have is an average of several engineers being polite. Pacia builds one from what the team has actually delivered — issue by issue, sprint by sprint — and shows you the inputs so you can decide how much to trust it.

Talk to us
Epic — Payments rebuild
Scope now
84 issues, 31 added since start
Completed
52 of 84
Throughput, last 6 weeks
6.2 issues/week
Forecast completion
mid-October, low confidence
Started
First child issue, 14 April

An epic starts at its first child issue, not the day it was raised.

Delivery dates fail for reasons that are measurable

Estimates are not usually wrong because engineers cannot estimate. They are wrong because scope grew and nobody counted it, because the epic sat untouched for two months and everyone kept quoting the original date, or because the throughput assumption came from a good fortnight rather than a representative one.

Pacia measures all three. Scope growth is tracked against total scope rather than the original batch — measuring against the initial batch is how a perfectly ordinary epic produced a scope-growth figure of 16,700%, because it started with one issue. Epics that have gone 90 days without activity are marked dormant and get no forecast at all, because nobody closes a finished epic in Jira and projecting one produced completion dates in 2033. And an epic is treated as starting at its first child issue, not at the moment someone raised the ticket, since epics get raised weeks before anyone works on them.

Those three rules came out of real data, and they are the difference between a forecast you can take to a stakeholder and a number that quietly embarrasses you.

A forecast should expose the rules behind it

Start date, scope growth and dormancy each change the answer materially. Pacia shows how each is treated rather than presenting a date without its workings.

The three rules that stop a forecast embarrassing you

  1. Epic raised 2 MarchClock starts at first child issue, 14 April

    Epics are raised weeks before anyone works on them. Dating from creation makes every team look slow.

  2. Grew 1 → 84 issues = 8,300% of plan31 of 84 added since start = 37% of total scope

    Measured against the initial batch, ordinary scope growth produced a figure of 16,700% on real data.

  3. Untouched 94 days, forecast: March 2033Marked dormant, no forecast issued

    Nobody closes a finished epic in Jira. Projecting one produces a date that discredits every other forecast on the page.

What you get to say with a straight face

  • A completion range with its workings attached

    Epic forecasts derived from the team’s observed throughput, showing the sample they were built from and their confidence. You can see when a forecast is weak, which is the part most tools hide.

  • Scope growth, correctly measured

    How much the epic has grown since work started, as a proportion of total scope. Plus what was added, and when, so "we agreed this in April" can be checked rather than debated.

  • Sprint reality, including what was added mid-sprint

    Planned, unplanned, delivered and carried out per sprint. Sprint membership changes are read from the Jira changelog, so work injected on day six shows up as injected work rather than being folded into the original plan.

  • Side-by-side epic comparison

    Compare epics against each other on the same measures when you are deciding what to cut, rather than comparing two differently constructed status updates.

  • Dormant work called out

    Epics nobody has touched for 90 days are flagged rather than forecast. Half of a typical roadmap review is discovering these.

Where this lives in Pacia

Common questions

How accurate are the forecasts?

They are as good as the team’s throughput history and Pacia tells you when that history is thin. Every forecast displays its confidence and the sample it was built from, and dormant or barely-started epics are excluded rather than given a spurious date. The honest framing is that this replaces a guess with a measured range, not with certainty.

Does this need story points?

No. Forecasts work from issue counts and observed throughput. If your Jira site has a populated story-points field, Pacia can use it — but it has to be identified explicitly, because a typical site has seven point-ish custom fields and only one of them is actually filled in.

Does it push anything back into Jira?

No. Pacia reads from Jira and never writes to it. Nothing in your board changes because you connected it.

Do product and delivery managers need a paid seat?

No. Billing counts active developers only. Product managers, delivery managers and programme managers are free, unlimited viewers.

See it against your own delivery data

Connect one repository and judge it on your own history rather than a demo dataset. Guided onboarding is included on every paid plan.

Talk to us