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 to Jira. It pairs what-if sliders (one value each) with a Simulation mode (Monte Carlo, thousands of runs drawn from ranges) and an AI box that proposes 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, a probability curve, or the numbers on the forecast cards — and the slider positions are forgotten as soon as the user leaves the tab.

The tab has three sub-views — Sprint, Project, and All Projects. The Sprint and Project sub-views show the same Delivery Forecast card, Target Date card and capacity model × demand model grid the Dashboard draws, so the same number means the same thing everywhere. All Projects draws its own build of those two cards and rolls the whole program up; in Simulation it 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 view: steps by calendar week (Monday to Sunday) 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 view (Program view chosen in the project picker) 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 appears whenever any issue is loaded (a due-date empty state appears inside it if none have dates). All Projects appears whenever there is at least one project in scope.
• When only one sub-view is possible the three buttons are 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. Only the sub-view on screen is kept; switching to another sub-view and back resets that view's sliders and ranges to where they start.

The controls row

One horizontal row sits under the forecast cards (and, on the Sprint and Project sub-views, under the capacity model × demand model grid) 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. It is not saved: leaving the tab turns it back on.
• 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. It is saved with the project, so it stays as it was left.

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% in steps of 1%. 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 All Projects sub-view offers the same four sliders with the same names. The Project sub-view has the same four, but its second slider is labelled Issues estimation.

Velocity and Capacity multiply together when both are non-zero: each person's capacity is multiplied by (1 + Velocity %) and by (1 + Capacity %), so +10% Velocity and +10% Capacity give 21% more capacity, not 20%. Issue estimation and Scope multiply together on the demand side in the same way.

Dragging any slider re-runs the cascade and moves the forecast cards immediately. Nothing is saved — there is no save button, and nothing is written to Jira.

Breakdown by user

A Breakdown by user checkbox (off by default) on the controls row 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 changes the picture only — the four sliders still apply to everyone; there is no per-person slider. A Reset all to baseline button below the sliders returns every slider to zero.

Cascade chart

The chart is headed Sprint Capacity vs. Remaining Demand, with the line Numbers under each sprint: demand / capacity. One column per sprint along the bottom, 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 up the side in pts, hrs or days.

• Bars — by default each sprint is one bar of demand, green while it fits the sprint's capacity (a deeper green the fuller the sprint is). Ticking Breakdown by user stacks it by assignee in a fixed colour per person with an Unassigned segment in grey; a person whose own demand is over their own capacity has their segment cross-hatched in red.
• Numbers under each column — the demand and capacity figures, demand / capacity, with demand in red when the sprint is over capacity.
• Capacity line — a thin horizontal mark inside each column 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.
• Overflow — with Cascade overflow ticked (the default), a sprint that is over capacity is drawn as a green part that fits under the capacity line and a red cross-hatched part above it, the work spilling into the next sprint. Untick it and each sprint is shown on its own with no spillover carried, and a sprint over capacity is drawn solid red.
• Projected columns — when overflow or the target date extends past the last planned sprint, the chart adds grey columns after it, numbered on from the last sprint and marked (proj) (for example S11 (proj)), each sized at the average capacity of the planned sprints. 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, planned 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 column; a vertical line marks the Projected completion column, green when it falls in or before the target column and red otherwise.
• Past target — columns after the target column are drawn grey.

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

A legend below the chart names what is drawn. With Breakdown by user off it reads Demand within capacity, then Overflow (Cascade overflow on) or Demand over capacity (Cascade overflow off), then Past target and Capacity. With it on, it lists each person by colour, Unassigned when there is unassigned work, and Overloaded, then Past target and Capacity.

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 Pace? 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 and capacity to target on one line (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, and one line with the chosen capacity model, demand model, the on-target odds and the likely-finish range — plus the "Complete" / "Never" terminal labels. The odds and the range belong to the date on the card: the simulation's runs are shifted so their middle lands on the forecast date, so 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 not measured yet — nothing discounted when the Effective capacity 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. When there is more the date does not show, an amber mark sits straight after the card title; it says, for example, Held by … — naming whoever is left holding the work past the last planned sprint, or work with nobody assigned to it — with the work still left and the rate it is being cleared at, and it also names work the date leaves out because the person holding it has no capacity. The gear on the card opens the capacity-model, demand-model and scope-growth controls; with Critical Chain only chosen the capacity-model dropdown gives way to the note Not used by the Critical Chain demand model — it ignores team capacity., as on the Dashboard. The card's See detail below link, and the collapsible Delivery Forecast — capacity model × demand model section beneath the cards, show every pairing at once. On this tab the section is drawn only when the comparison could be worked out; when it could not, the section is not shown. Since 2026-09-04 the cards, the grid and every number behind them are the one component the Dashboard draws — computed once, drawn once — so the two tabs cannot disagree. 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 P pin marks the projected delivery (the same date as the Delivery Forecast card) — both state their calendar dates on hover, and both are placed by one shared date-to-column rule, so a target beyond the last planned sprint lands on a projected column 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 are grey as past-target.

A yellow notice sits at the very top of the tab when team members are set up but none of them are allocated to this project: it says Team capacity for the project reads 0 and points to the Team Allocation Matrix on the Projects tab.

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., Underperforming. Overflow begins in Sprint 6, completion pushed to Sprint 9.) so the consequence of the slider change is always one glance away. The statements are shown in What-If mode only, and are hidden while an AI answer is on screen.

Simulation (Monte Carlo) mode

Switching to Simulation mode replaces each single-value slider with a low–high range (a slider with two handles, captioned for example Velocity range and −15% to +10%) and replaces the cascade chart with a probability curve. The forecast cards stay at the top.

Uncertainty ranges

In Simulation mode each variable is a low–high range rather than a single value. On the Sprint and Project sub-views the ranges start at velocity −15% to +10%, issue estimation −10% to +15%, scope −5% to +15%, capacity −15% to +10%, and can be adjusted; Reset all to baseline below them puts them back. There are no Conservative / Realistic / Optimistic preset buttons. (The All Projects sub-view starts every range at −15% to +15%; see below.)

Probability chart

The chart is headed Delivery Probability Distribution. Along the bottom are the sprints (fractional half-sprint steps allowed), with the sprint name and start date; up the side is the chance of having finished by that sprint (Likely on target).

• The chart is built by running the cascade 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 one team-wide draw (everyone has a similar good or bad sprint) and a separate draw for each person (individuals still vary independently).
• The curve is smoothed through the counts so it reads as a curve rather than steps.
• A dot labelled 85% marks where the curve crosses 85% (the planning-safe point) — blue on the Sprint sub-view, green on the Project sub-view; a purple dot marks the target with its N% on target label.

Simulation KPI row

Above the 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, with by and the target column's name beneath. Green 70% and above, amber 50–69%, red below 50%.
• Finish on Time? — Yes / Maybe / No from that same probability, with N% of runs on target beneath.
• Expected slip — average sprints late among runs that missed, shown as None or +N sprints, with the share of runs that missed beneath; green when none, amber up to 1 sprint, red above.
• Feasibility — a 0–100 plan-feasibility score banded High / Medium / At Risk / Critical (ALGORITHMS section 8); reacts to the sliders like the other cards.

On the Project sub-view, the weekly chart and the Delivery Forecast card above it are meant to share one weekly capacity rate (ruling 2026-07-09): each week's capacity comes from the same team figures, and the card's Capacity to target adds up 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 every week carries the same capacity, the chart's weekly capacities up to the target add up to the card's figure. Where people's hours differ week by week, or time off falls in the window, the weekly figures are not all the same.

AI box (Sprint view)

The box sits below the sliders and the chart, in What-If mode only. On the Sprint sub-view it appears only once an AI provider and its key are saved in Settings → AI Features; without them nothing is drawn in its place. That is true in every edition — the app inside Jira, the web app connected to your own Jira, and the demo — and in each of them the question and the project's figures described below are sent to the AI provider chosen there. When Hide people's names from the AI is ticked in Settings → AI Features, each person is sent as "Person A", "Person B" and so on, and the names are put back into the answer.

It has a text box with the placeholder Ask a question about the project... and an Analyse button.

The user's free-form question is sent along with the project's figures: 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 AI returns a structured answer with these parts:

• Summary — a short narrative answer.
• Impact assessment — four cards (Capacity, Schedule, Risk and Team), each with a severity (positive / negative / neutral) shown by its colour, a short label, and a one-sentence detail.
• Recommendations — suggested actions, each with a title, a detail and a 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.

On screen the answer shows the summary, the recommendations, the four impact cards, a blue line 📊 Sliders and graph updated: listing the slider changes, and a Per-sprint adjustments applied: list. The four sliders are set from the suggested values, held within ±50. Per-sprint changes are matched against the actual sprint names and applied to each named 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.

When the answer contains a number that none of the figures sent to the AI contain, a yellow notice sits above the answer naming it: This figure did not come from Project Commander: … Nothing on this screen worked it out, so check it before acting on it. Every other number in the answer came from the app. The answer itself is kept.

The AI never computes the forecast itself — it only proposes adjustments, and the app's own forecast applies them.

While an answer is being worked out and while it is on screen, the sliders are greyed out and cannot be moved. ✕ Clear, beside Analyse once there is an answer, empties the box, forgets the conversation and puts every slider back to zero.

How the answer is asked for (changed 2026-09-10). The shape above is now asked of the AI in the way the chosen provider supports — Anthropic is given it as a tool it must call, OpenAI as a response format it must obey, Google as a response schema — and the screen reads the fields directly. Until that day the shape was only described in the prompt, and each screen then searched the reply text for the first pair of braces it could find and parsed that; the four impact cards had already broken differently on each provider once and been patched by hand. A reply that does not match the shape now says so plainly rather than showing half of it.

Follow-up questions (added 2026-09-10). The last three questions and their answers go with each new question, so “and if we also lose Alice?” is answered in the light of the one before it. Until that day each question here was sent alone. ✕ Clear forgets the conversation.

Loading / error

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

Project view

Same cards, controls and sliders as the Sprint view. The chart is headed Weekly Capacity vs. Demand, with the line Numbers under each week: demand / capacity; its columns are calendar weeks (Monday to Sunday), each labelled with its Monday's date. The weeks run from this week to the week of the latest issue date (at most 52 weeks); overdue work lands in the first week. An issue's demand is placed by its due date — an issue with no due date of its own takes the end of the sprint it is in, the same due-date rule every tab uses. When an issue has both a start date and a due date, its demand is split evenly across every week from the start week to the due week; an issue with only a start date is placed in its start week.

On this chart a week that is over capacity is drawn as a solid red bar, whether or not Cascade overflow is ticked. Weeks after the target, and projected weeks past the last dated week, are grey (the legend calls them Post-target / overflow). Once any slider is moved away from zero, faint Baseline bars and capacity marks behind each week show where it stood with every slider at zero.

With Critical Chain only chosen as the demand model in the Delivery Forecast card's gear, a line above the sliders says the finish date comes from the chain of blocking work, not capacity, and the four sliders are greyed out.

Undated issues alert

Issues with neither a due date nor a start date can't be placed on the weekly timeline, so they are called out in a small ⚠ alert above 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 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, with by and that week's date beneath), 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 box (Project view)

Same structured answer, notice and rules as the Sprint view, and the figures sent are grouped by week. The differences:

• The box is always drawn in What-If mode, headed Ask a What-If Question with the line Describe a scenario to see its impact on the plan timeline, and the placeholder Describe a scenario, e.g. 'What if 3 members take PTO the same week?'. With no AI provider and key saved in Settings → AI Features, it reads Add your Anthropic API key in Settings → AI Features to enable AI analysis. in place of the text box.
• The Project view applies only the 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 right-hand end of the tab bar: 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, which is greyed out while every slider is at zero. There is no per-slider statement on this view.
• Across the top are this view's own Delivery Forecast card and Target Date card. The Delivery Forecast card reads the program finish (the latest project to finish, noted Latest project to finish), Remaining: and Capacity to target: (per unit, so points and hours never mix), On target or Not on target · N days late, Capacity model:, Demand model:, On target odds: and Likely finish:. Its capacity model reads "Per project" for a multi-project rollup. When the program cannot finish the card reads Never with Scope outpacing delivery. Its gear offers the capacity model (including Per project when there is more than one project), the demand model, and Scope growth method — a tick box that applies one scope-growth assumption (Average or Manual, at a rate per week) to every project; unticked, Each project uses its own setting. The Target Date card defaults to the latest target across the projects (Latest target across projects), and is editable on the card in the field Set program target date: typing a date sets a manual program target (Manual program target) that the program forecast, the comparison grid, the on-target odds, and Simulation on this view all honor; Reset to auto returns to the automatic latest-deadline rollup. The Dashboard and Scope program views keep the automatic date.
• The collapsible Delivery Forecast — capacity model × demand model grid rolls every pairing up across the projects. It starts closed; clicking a square sets the card, the program total and the table's Forecast column to that pairing.
• 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." A line beneath explains the three columns.
• The four sliders run through the same forecast calculation 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 (two sliders per variable, low and high, each range starting at −15% to +15%, with a Reset ranges button) and replaces the per-project table with the Program Delivery Probability panel. Its first line says how many times the selected scenario was run (600) and that a run is on time only if every project lands by the program target.

• On-target probability — the share of runs in which the whole program finishes by the program 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, shown as None or +N wks.
• Probability curve — the chance of being finished by each date, with the target marked.
• Weakest links — which project is most likely to make the program late — a table of each project's On-time odds, Likely finish (P50) and Expected slip, 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, with no capacity as its slip.

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 panel says Add at least one project that runs on sprints to see delivery odds — the simulation needs a sprint cadence to vary against. 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 to see risk analysis.
• No data — Project view — No Plan Data — Configure JQL or enable Test Mode to see plan risk analysis.
• No dates — Project view — Issues Need Due Dates — Plan Risk analysis uses issue due dates to build a weekly timeline. Add due dates to your issues to see risk analysis.
• No projects — All Projects view — No projects to show.
• Estimation mode — chart 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 sub-view is not offered in the program view.

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 probability chart, 5,000 in the Project probability chart; the card/grid on-target odds use a 250-run pass and the All Projects program Simulation 600.
• Weekly bucketing — section 5, and the What-If Project view's weekly bucketing.
• 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 not kept — leaving the tab, reloading the page, or switching sub-views puts every slider and range back where it starts. The sliders never write to the project's settings or to Jira. The settings on this tab that are saved are the ones that belong to the project: Include backlog, Breakdown by user, the program target on the All Projects Target Date card, and whatever is changed through the gears on the Delivery Forecast and Target Date cards.
• From the Dashboard — the Dashboard's AI Insights box could suggest slider values and link here with them applied. That box was removed on 18 September 2026; the panel that replaced it answers what a change would do directly, rather than sending you to this tab to try it.
• No effect on the forecast outside this tab — the Sprints, Scope, and Dashboard forecasts all read the project's settings (not the What-If sliders), so they stay on baseline until the user changes the underlying settings explicitly.
• One AI setting — every AI feature in the app uses the provider and key saved in Settings → AI Features; if the key works in this tab it works everywhere.