What-If Tab — Feature Guide

What it's for

The What-If tab is the project's sandbox: a place to test how velocity changes, estimate inflation, scope growth, and capacity changes affect the delivery forecast — without touching real data and without writing anything back. It pairs deterministic what-if sliders with a probabilistic Simulation mode (Monte Carlo) and an AI chat that proposes coherent slider values from a free-form question.

The audience is delivery managers, programme leads, and product owners who need to answer questions like what if we lose Alice for the next sprint?, what if scope grows 20%?, or what if we add a developer? The tab makes the answer visible as a cascade chart, an S-curve, or a dollars-and-deadlines KPI line — and as soon as the user navigates away, the project is exactly as it was before.

The tab has three sub-views — Sprint, Project, and All Projects — and each shows the same Delivery forecast card and capacity-model × demand-model grid the Dashboard and Scope tabs use, so the same number means the same thing everywhere. All Projects rolls the whole program up and, in Simulation, reports the program's odds and which project is the weakest link.

Sub-views (Sprint / Project / All Projects)

Three buttons switch between the sub-views. They sit at the start of the tab's one row of controls, before the What-If / Simulation switch:

• Sprint — the sprint-level view: steps through the actual sprints.
• Project — the weekly time-axis view: steps by ISO calendar week from issue due dates, so it works even when a project is not run on sprints.
• All Projects — the whole-program rollup: no timeline, every project rolled up into one program forecast (see the All Projects view section below).

• Sprint appears when a single project is selected, that project has sprints, and sprint mode is on — in the program (All projects) view the Sprint sub-view is unavailable, because sprint cadences from different projects cannot cascade together and the program forecast comes from the one shared rollup (the All Projects sub-view); Project whenever any issue is loaded (a due-date empty-state appears inside it if none have dates); All Projects whenever there is at least one project in scope.
• When only one sub-view is possible the toggle is hidden and that sub-view loads automatically.
• Each sub-view has its own What-If / Simulation switch, next to the sub-view buttons on that same controls row. The wrapper mounts only the active sub-view and unmounts the others, so slider positions are not carried over — switching to another sub-view and back resets that view's sliders to baseline.

The controls row

One horizontal row sits under the forecast cards and above the sliders, on every sub-view. Left to right: the three sub-view buttons, the What-If / Simulation switch, then the display choices.

• Cascade overflow (on by default) — work that does not fit a period spills into the next one. Untick it to see each period on its own. Sprint and Project sub-views.
• Include backlog (off by default) — count issues that sit in no sprint. All three sub-views, and it is the same project-wide setting the Dashboard and Scope tabs read, so changing it here changes it everywhere.
• Breakdown by user (off by default) — split each chart bar into a segment per assignee. Sprint and Project sub-views.

The All Projects sub-view offers Include backlog only: it has no timeline and no chart, so there is nothing for the other two to act on.

Sprint view

Sliders

Four horizontal sliders, range −50% to +50%. Each is labelled at both ends with what moving it means, and carries a line beneath saying what the current position assumes:

• Velocity (Slower … Faster) — scales sprint capacity. Negative = team running slower than recent history; positive = faster. At zero it reads ✓ Delivering exactly what was committed.
• Issue estimation (Smaller … Larger) — scales sprint demand. Negative = work smaller than estimated; positive = larger. At zero it reads ✓ Estimates assumed accurate.
• Scope (Less … More) — scales sprint demand. Negative = backlog tightening; positive = scope growth. At zero it reads ✓ Scope at plan.
• Capacity (Less … More) — scales sprint capacity directly. Negative = absences / context-switching; positive = headcount or efficiency. At zero it reads ✓ Capacity at plan.

The same four sliders, from one shared definition, appear on all three sub-views.

Velocity and Capacity multiply together when both are non-zero (capacity *= (1 + velocity/100) × (1 + capacity/100)). Issue estimation and Scope multiply together on the demand side identically.

Dragging any slider re-runs the cascade simulation in real time. Releasing the slider commits the value to local component state — there is no save button.

Breakdown by user

A Breakdown by user checkbox (off by default) splits each cascade bar into per-assignee demand segments instead of one aggregate bar, so you can see whose work sits in each sprint. It is a display option only — the four sliders still apply globally; there is no per-member slider override. A Reset all to baseline button returns every slider to zero.

Cascade chart

The right-hand panel is a stacked cascade bar chart. One bar per sprint along the X-axis, in calendar order (sorted by sprint start date — a Jira board's own list order is not always chronological, and the chart never follows it); demand on the Y-axis in points or hours.

• Bars — by default each sprint is one aggregate demand bar; ticking Breakdown by user stacks it by assignee in deterministic name-hash colours with an Unassigned segment in grey.
• Capacity line — a thin horizontal mark inside each bar at the sprint's capacity. For the ACTIVE sprint this is its remaining capacity — the sprint's figure scaled to the days still ahead (ruling 2026-07-10) — so a half-finished sprint shows a half-height line and its over/under read matches the Sprints tab header. A sprint Jira still marks future whose dates have passed shows no capacity line at all — it was never started and its days are gone (decision 2026-09-03) — which is what the Sprints tab header and the Delivery forecast card say of it too.
• Cross-hatched overflow — a Cascade overflow checkbox (on by default) renders demand above capacity as a 45° red cross-hatch carrying spillover into the next sprint; untick it and each sprint is shown on its own, with no spillover carried.
• Virtual sprints — when overflow or the target date extends past the last planned sprint, the chart appends faded virtual columns (labelled S7, S8, …) sized at the team's average sprint capacity. The timeline never goes blank: every column from the first bar through the target (and the projected completion) stays visible — including zero-demand planned sprints and empty projected columns — and every column always shows its calendar date, real sprint or not. When the chart has many columns, the sprint names and the demand/capacity numbers thin out to every 2nd–4th column for width, but the dates never do.
• Markers — a vertical purple line marks the Target sprint; a vertical line marks the Projected completion sprint, green when P ≤ T and red otherwise.

(Ghost "baseline" bars behind the active bars are a feature of the Project view's chart, not this Sprint-view cascade.)

A legend below the chart explains the assignee colours, the unassigned grey, the overload cross-hatch, and the capacity line.

Forecast cards + comparison grid

Across the top of the tab — above the controls row, in both What-If and Simulation modes — sit the same Delivery forecast card and Target date card as the Dashboard (the On-plan and Progress cards are hidden, and the two are widened to fill the row). They stay on screen in Simulation so the Target date card's gear is always within reach. That gear and the Target Date field on the Projects tab's Add / Edit Project form set the same date: a project's target lives in one place, its own record, and every screen reads it from there (2026-09-03). The Delivery forecast card carries the projected finish date, work remaining, capacity to target (clipped at the target date — when the plan holds capacity beyond the target, an extra line states N pts capacity available after target date), the on-time verdict, the chosen capacity model and demand model, the on-target probability and likely-finish range — and the "Complete" / "Never" terminal labels. The odds and the range belong to the date on the card: the simulation measures how much that date could vary, so the middle of the likely-finish range is always the forecast date beside it, and the odds are the odds of that date. Anything the forecast counts — the backlog when Include backlog is on — moves all three together. The same amber notices as the Dashboard card apply here: Efficiency assumed when the Effective model has no measured history, and, when the Team or Effective model comes out at zero while work remains, the sentence saying which of the three states it is — no sprint dates, nobody on the Team & Capacity tab, or people there with no capacity typed. A date that runs past the last planned sprint carries the same Held by … line as the Dashboard card, naming whoever is left holding the work — or work with no one assigned when it belongs to nobody — together with the work still left and the rate it is being cleared at. Its gear opens the capacity-model, demand-model and scope-growth controls. Beneath the cards, the collapsible capacity model × demand model grid shows every pairing at once. The sliders move all of these live with each drag, exactly as they move the cascade chart.

On the cascade chart itself, the purple T pin marks the target date and the green/red P pin marks the projected delivery — both state their calendar dates on hover, and both are positioned by one shared date-to-column rule, so a target beyond the last planned sprint lands on an extension column (grey, with projected calendar dates under each name) instead of snapping back onto the plan. The dashed vertical divider separates the plan from everything after the target date (hover it for the target date), and columns right of it grey out as past-target.

Per-slider risk statement

Each slider has a one-line plain-English statement that updates as the user drags. The statement names the affected sprint (e.g., Overflow begins in Sprint 6, completion pushed to Sprint 9) so the consequence of the slider change is always one glance away.

Simulation (Monte Carlo) mode

Switching to Simulation mode replaces single-point sliders with low/high range pickers and replaces the cascade chart with an S-curve.

Uncertainty ranges

In Simulation mode each variable is a low–high range rather than a single value. The ranges start from a realistic default spread (velocity −15 to +10, estimation −10 to +15, scope −5 to +15, capacity −15 to +10) and can be adjusted. There are no Conservative / Realistic / Optimistic preset buttons — the defaults are simply applied.

S-curve chart

X-axis is sprint index (fractional 0.5 steps allowed). Y-axis is cumulative probability of completing by that sprint.

• The chart is built by running the cascade simulation many times — 2,000 runs in the Sprint sub-view and 5,000 in the Project sub-view — with each run drawing values randomly inside the ranges.
• Each run applies a 50/50 split between a single global trend factor (everyone has a similar good or bad sprint) and per-user noise (individuals still vary independently).
• The chart fits a Catmull-Rom spline through the cumulative-probability histogram so the curve reads smoothly.
• A green dot marks the P85 crossing (planning-safe sprint); a purple dot marks the target sprint with its on-time probability label.
• Optional ghost curve in faded grey shows a baseline scenario for before/after comparisons.

Simulation KPI row

Above the S-curve:

A one-line verdict sits above the numbers on both the Sprint and Project sub-views: Target likely / Target uncertain / Target very unlikely, followed by how many runs were made, what the sub-view steps by, and the four ranges they were drawn from — 2,000 runs · stepped by sprint · … and 5,000 runs · stepped by calendar week from issue due dates · …. The verdict reads from the same on-time bands as Finish on Time? beside it, so the two can never disagree; and because each line names its own basis, the two sub-views giving different odds for one project explains itself.

The sprint the odds are measured against is the project's target date resolved to a column — the same shared computation the Target date card shows, extending past the last planned sprint when the target falls beyond the plan; only when no target date exists does it fall back to the last sprint with demand. There is no separate target control on this tab: the Target date card's gear is the one place the target is set, and that card stays on screen in Simulation mode.

• On-target probability — % of runs that finished on or before the target. Green ≥ 70, amber 50–69, red < 50.
• Finish on Time? — verdict pulled from the probability: Yes / Maybe / No.
• Expected slip — average sprints late among runs that missed; green when 0, amber ≤ 1, red > 1.
• Feasibility — a 0–100 plan-feasibility score banded High / Medium / At Risk / Critical (ALGORITHMS section 8); reacts to the sliders like the other cards.

The weekly chart and the Delivery forecast card above it share one weekly capacity rate: every chart week's capacity bar equals that rate, and the card's Capacity to target equals the same rate over the weeks between today and the target (clipped at the target; the current week — and, with sprints on, the active sprint — contributes only its remaining day-fraction, ruling 2026-07-10). When the plan's due dates cover every week up to the target, the chart's bars up to the target sum exactly to the card's figure; weeks with no due work draw no bar, so on sparse plans the bar sum can be less than the card.

AI Chat (Sprint view)

A chat card sits below the cascade chart with placeholder text Ask a question about the project… and an Analyse button.

The user's free-form question is sent along with a structured payload: per-sprint capacity / demand / overflow, per-issue details, team context, per-assignee workload, time off, holidays, velocity history, backlog summary, and a one-line current-status string (On track, 2 sprints late at baseline, etc.).

The model returns a structured answer with these parts:

• Summary — a 2–4 sentence narrative answer.
• Impact assessment — four cards (capacity, schedule, risk, and team impact), each with a severity (positive / negative / neutral), a short label, and a one-sentence detail.
• Recommendations — 2–4 suggested actions with priority high / medium / low.
• Suggested slider values — proposed changes to the four sliders, in percentage points.
• Per-sprint adjustments — for each named sprint, an absolute change to its capacity and demand, with a short reason.

The four sliders are written back from the suggested values, clamped to ±50. Per-sprint deltas are validated against the actual sprint name list and applied as absolute values to the sprint's capacity and demand. The cascade chart re-runs immediately with the new inputs; the user sees the slider positions move and the bars shift.

The AI never computes the forecast itself — it only proposes adjustments, and the deterministic engine applies them.

No-key state

When no AI API key is configured in Settings → AI Features, the chat box reads Add your Anthropic API key in Settings → AI Features to enable AI analysis and the textarea / button are hidden.

Loading / error

While the AI call is in flight the Analyse button reads ⏳ Analysing… and is disabled. Auth errors are caught and shown as Invalid API key. Check your key in Settings → AI Features. Other errors render the model's error text.

Project view

Same chart and chat shape as Sprint view, but the X-axis is ISO calendar weeks (Mon–Sun) and the demand is bucketed by the issue's due date. When an issue has both start and due dates the demand is spread evenly over the spanned weeks, prorated by the weekday-overlap fraction (a week the range only touches Mon–Wed counts as 3/5 of the issue's weekly share).

Undated issues alert

Issues without a due date can't be placed on the weekly timeline, so they are called out in a small ⚠ alert beneath the chart — "N issues without dates — not shown in the chart" — listing the issue keys when there are ten or fewer, rather than dropping them silently.

Simulation result cards

Switching the Project view to Simulation mode runs a Monte Carlo forecast and shows four cards above the probability-distribution chart. The week they are measured against is the project's target date resolved to a week; as on the Sprint sub-view there is no separate target control here, because the Target date card at the top of the tab is the one place the target is set. The four are On-target probability (the share of simulation runs that finish by the target week), Finish on Time? (Yes / Maybe / No read from that same run probability at the shared 70%/50% bands — the identical rule the Sprint sub-view uses, so it reacts to the sliders), Expected slip (the average delay past the target across the runs that missed it, shown as None or +X weeks, with the percentage of runs that missed), and Feasibility (a 0–100 plan-feasibility score banded High / Medium / At Risk / Critical — capacity vs demand, delivery timing, over-capacity periods, and overflow; the rule is ALGORITHMS section 8).

AI Chat (Project view)

Same structured answer and rules as the Sprint view, and the payload is week-bucketed. The one difference: the Project view applies only the chat's suggested slider values — it does not apply the per-sprint adjustments the way the Sprint view does.

All Projects view

The third sub-view has no timeline — it rolls every project up into one program forecast, the same rollup the Dashboard's Program View and the Scope program view use. It follows the project picker at the top of the tab: with Program view selected it covers every registered project; pick a single project and it shows just that one.

The What-If / Simulation switch sits on the shared controls row, the same as the Sprint and Project sub-views, with Include backlog beside it.

What-If mode

• The left column has the four sliders (Velocity, Issue estimation, Scope, Capacity) and a Reset all to baseline button, level with the per-project table beside it.
• The header shows the rolled-up Delivery forecast card and Target date card. The Delivery forecast card reads the program finish (the latest project to finish), the work remaining and capacity to target (per unit, so points and hours never mix), the on-target odds and likely-finish range, and the two models — its capacity model reads "Per project" for a multi-project rollup. The Target date defaults to the latest target across the projects, and is editable on the card: typing a date sets a manual program target that the program forecast, the comparison grid, the on-target odds, and Simulation on this view all honor; clearing the field (or Reset to auto) returns to the automatic latest-deadline rollup. The Dashboard and Scope program views keep the automatic date.
• The collapsible capacity model × demand model grid rolls every pairing up across the projects.
• A per-project table lists each project's Demand (work remaining), Capacity (to the target), and Forecast (projected finish), with a Program total row per unit. A project that cannot finish reads "Never"; when all work is done the program reads "Complete."
• The four sliders run through the same forecast engine the single-project views use, so a project's numbers match its own Sprint / Project / Dashboard views at every slider position.

Simulation mode

Flipping to Simulation swaps the sliders for uncertainty ranges (a low–high band per variable) and replaces the per-project table with the Program Delivery Probability panel:

• On-target probability — the share of runs in which the whole program finishes by the program target. A run counts as on time only if every project lands by the target.
• Finish on time? — a plain Yes / Maybe / No read from that probability.
• Expected slip — how far past the target the late runs land on average, in weeks.
• Probability-over-time curve — the chance of being finished by each date, with the target marked.
• Weakest links — a table of each project's own probability of landing by the program target, worst first, so the project dragging the program down is at the top; a project that can never finish sits at the very top, marked Never.

The program odds work by forecasting each project on its own, running the sprint-based ones many times, and combining them so that in each run the program finishes with its latest project. If no project in the program runs on sprints with a team, no probability is shown (the same way a single sprintless project shows none). Each project is forecast on its own team's capacity, with that project's allocation from the Team Allocation Matrix (Projects tab) applied — so a person split across projects is counted at their allocated share, not at full capacity on each.

Cross-cutting modes and empty states

• No data — Sprint view — No Sprint Data — Configure sprints or enable Test Mode.
• No data — Project view — No Plan Data — Configure JQL or enable Test Mode.
• No due dates — Project view — Issues Need Due Dates — Plan Risk uses due dates to build a weekly timeline.
• Estimation mode — bar labels switch between pts, hrs, days depending on the project's mode and time unit.
• Program view — the All Projects sub-view rolls up every registered project; use it for program-level what-if and simulation. The Sprint and Project sub-views remain single-project in nature.

How the numbers are computed

• Cascade simulation — see ALGORITHMS section 1 (Delivery Forecast) and the slider semantics in the Appendix.
• Monte Carlo — section 2 (Monte Carlo Delivery Confidence). Run counts: 2,000 in the Sprint S-curve, 5,000 in the Project S-curve; the card/grid on-target odds use a 250-run pass and the All Projects program Simulation 600.
• Weekly bucketing — section 5 plus the Plan-Risk weekly bucketing variant; the weekday-overlap proration uses the ISO-week utilities documented in the Foundation Utilities section.
• Feasibility score — section 8.
• AI prompt + response schema — sections 18 (What-If Sprint AI) and 19 (What-If Project AI).

Effects on other parts of the app

• Slider state is ephemeral — closing the tab, reloading the page, or switching sub-views resets every slider to baseline. Nothing writes back to the project config or to Jira.
• Dashboard AI Insights link — when the Dashboard's AI suggests slider values, the Open the What-If tab to explore this scenario interactively link opens this tab with those values pre-applied.
• No effect on the deterministic forecast outside this tab — the Sprints, Scope, and Dashboard forecasts all read the project config (not the What-If sliders), so they stay on baseline until the user changes the underlying configuration explicitly.
• AI fallback alignment — Auto-Level AI Review and Risks Accept dialog use the same provider/key configured in Settings; if the key works in this tab it works everywhere.