Forecast when initiatives will land

The roadmap can tell you when each initiative is likely to finish, and what would change if you added an agent or a reviewer. Nobody estimates anything: the forecast comes from how long agent runs and reviews have actually taken on this project.

1
Turn on the forecast
Open Initiatives in the project sidebar, switch to the Roadmap tab, and turn on Forecast in the toolbar. Each initiative that has work left gets a diamond on its bar: the date its remaining objectives are projected to finish.
Your choice is remembered per project, so the forecast stays on next time you open the roadmap.
2
Pick the horizon
Acceptance places the diamond where the initiative's remaining work is projected to reach the acceptance queue, the point where agents hand off to reviewers. Done places it where that work is also projected to be reviewed and accepted. If an initiative has no review history yet, the Done horizon falls back to its acceptance date.
3
Read the diamond
The date sits above the diamond. The number inside is the initiative's finish order among everything on the chart, so 1 lands first; it can differ from the bar's position on the chart. Click the diamond to see both projected dates, how many objectives are left out of the total, the agents and reviewers the simulation used, and a confidence level.
A solid diamond is the real forecast. A dashed one means What if is on and you're looking at a hypothetical.
4
Check the numbers behind it
The toolbar shows the figures the forecast runs on, all taken from this project's own history. Total agents is the number of distinct agents active on the project in the last 90 days. Claim latency is the average time per objective, from scheduling to acceptance: the wait for a developer to pick it up plus the build. With the Done horizon you also see Total reviewers, the distinct people who signed off acceptances in the last 90 days, and Review time, the average time an objective spends in acceptance before sign-off.
5
Explore a what-if
Turn on What if to try different numbers without changing the real ones: more or fewer agents, a faster or slower claim latency, and, with the Done horizon, more or fewer reviewers and a different review time. The diamonds move as you type. Turn What if off to go back to the real forecast; what you typed is kept, so turning it back on restores your scenario.
Setting fewer agents than objectives already in progress is allowed. The simulation queues the extra work behind the agents you gave it.
6
Decide whether to count working hours only
The real forecast counts only working hours, weekdays from 09:00 to 18:00 UTC, for the parts that need a person: a developer picking up an objective, and a reviewer signing it off. The build itself is agent work, so it counts around the clock. Under What if you can turn Working hours off to see the forecast if people were available at any hour; the diamonds turn dashed, because that's a hypothetical too.

How the forecast is worked out

Every remaining objective on an initiative shown on the chart goes into one shared simulation, so initiatives compete for the same agents and reviewers rather than each assuming it has the whole team.
Objectives already in progress go first. Then the queue follows the roadmap: an initiative blocked by another waits for it, initiatives without a dependency keep their roadmap order, and within an initiative scheduled objectives go before backlog, then by date.
Each objective goes to whichever agent frees up first and takes the project's average claim latency. That gives the acceptance date.
A second pass sends each objective, in the order it reaches acceptance, to whichever reviewer frees up first for the average review time. That gives the done date.
An initiative's projected date is when the last of its own remaining objectives finishes.

An initiative gets no diamond when it has no remaining work, isn't shown on the chart, or the project has no completed objectives to learn from yet. For an initiative shared across projects, only this project's objectives are counted, so the forecast can look early if more of its work sits elsewhere.

How confident it is

The popover shows a confidence level based on how much history the averages come from.

High

At least eight completed objectives to learn from.

Medium

At least three.

Low

Fewer than three.

If those objectives took very different amounts of time, confidence drops one level. With the Done horizon, the lower of the build and review confidence is shown.

What moves the forecast

Adding or removing objectives. More remaining work pushes the diamond out; finishing or discarding work pulls it in.

Rejections. A rejected objective goes back into the queue and has to be built and reviewed again.

Dependencies. Marking an initiative as blocked by another means none of its queued work starts until the blocker's work is projected to finish.

Roadmap order and scheduling. Reordering initiatives, or scheduling backlog objectives, changes what goes through the queue first.

What's on the chart. Only initiatives drawn as bars compete for agents and reviewers. Hiding one, or filtering out shipped or workspace-wide initiatives, removes its work from the simulation.

How fast the team actually works. As agents finish runs and reviewers sign off, the averages update, and so does the forecast.

What it deliberately doesn't do. There are no estimates, story points or capacity sheets to fill in. Every objective is treated as taking the project's average time, because objectives are meant to be small, single-run outcomes. If one initiative's objectives are much bigger than the rest, its forecast will be optimistic; split them into smaller objectives.

Related guides

Track initiatives and the roadmap →

The rest of the Roadmap tab: dates, dragging to reschedule, objective dots and warnings.

Organize with Initiatives →

Create initiatives, set target dates and dependencies, and release when the work ships.

Delivery health →

Cycle time and where work waits, across the workspace.

← Track Initiatives and the Roadmap Audit Chain Health →