Scope Tab — Feature Guide

What it's for

The Scope tab tells the user how scope has changed over the life of the project, what's left, and whether the team is keeping up with — or falling behind — its own moving target. It exists because scope is rarely a constant: stories get added, estimates get revised, work gets pulled, and the deadline does not always move with them. The tab makes that movement visible.

It answers four questions: how much scope is in the project right now; how much of that has been done; how much it has grown or shrunk since a baseline date; and at the current pace, when will all the work finish.

The audience is delivery managers, programme leads, and engineering managers who own the deadline. The tab is a single project view; in Program All mode the scope numbers aggregate across projects but sprint-marker overlays are suppressed because cadences differ.

Header / stat cards

Four stat cards across the top.

Burned & Remaining card

Shows the breakdown of the current scope.

• Burned — sum of estimates on done issues, plus the percentage of total scope they represent.
• Remaining — sum of estimates on non-done issues, plus the percentage they represent.
• When a Start Date is set, the card adds a third line: Scope at start vs current scope, with a signed percentage change. The percentage colours amber at +20–40%, red above +40%.

Start Date card

Anchors the timeline. Choose how the start is defined:

• Fixed — explicit calendar date entered by the user.
• Earliest start — the oldest issue's created timestamp; the default.
• Earliest due — the issue with the earliest dueDate.
• Earliest sprint start — the start of the first sprint, when sprint mode is on.

The card shows the resolved date underneath the chosen method. Switching method re-anchors the chart and the burndown immediately.

Target Date card

Anchors the deadline. Three methods:

• Fixed — explicit date.
• Latest due — the latest dueDate across the issue set.
• Latest sprint end — the last planned sprint's end date.

The resolved date shows beneath the method label. The chart draws a red dashed reference line at the target. The ideal-burndown line runs from the starting scope at Start Date down to zero at Target Date.

Delivery Forecast card

Shows the projected completion date for all remaining work.

• Primary value: a single date or Never when scope-growth-with-no-velocity makes completion infeasible.
• Below the date: throughput rate that produced the forecast (e.g., 22 pts/week).
• Scope-growth controls: a three-way selector — None, Detected (use the project's historical growth rate), What-If (custom rate). When Detected or What-If is active and growth ≥ velocity, the card switches to the never finishes state.
• A Velocity sprint count dropdown (3 / 5 / 8 / 10) sets the rolling window used to compute throughput. Shorter is more reactive, longer is smoother.

Scope timeline chart

The primary chart. Collapsible Scope Timeline section. X-axis = time bucketed by the period selector; Y-axis = points (or hours / days under time mode).

Period selector and navigation

Buttons across the top of the chart: All Time, Weekly, Biweekly, Monthly, Quarterly, Yearly, Sprint. Plus left/right arrow navigation, a date picker for jumping to a specific period, and a Reset button that re-centres on today.

Sprint mode buckets by the project's actual sprint windows so each x-axis tick corresponds to one sprint. It is hidden when sprint mode is off and when the project has no sprints yet.

In All Time mode, the X-axis spans from the resolved Start Date through today (or through the projected end when forecast is enabled). Period navigation is disabled in this mode — there is no period to step.

Core series

The chart renders a burndown view and a burnup view of the same scope data — together they tell the same story from two angles.

Burndown view (start-high, end-low):

• Scope (purple, solid) — total estimate of all currently active issues, replayed back through the changelog so the chart shows the historical scope at each bucket.
• Remaining (orange, solid) — Scope minus cumulative completed work. Falls only when work is done; rises when scope is added faster than it is completed.
• Ideal Burndown (blue, solid) — straight line from starting scope at Start Date to zero at Target Date. Position above the line = ahead of pace; below = behind.

Burnup view (start-low, end-high):

• Burnup (green, solid) — cumulative completed work over time. Mirrors the Remaining line: every point burned down lifts the Burnup line by the same amount. Stays flat across periods where nothing closed.
• Ideal Burnup (light green, dashed) — straight line from zero at Start Date up to the current Scope total at Target Date. Position above the line = ahead of pace; below = behind. Re-anchors when Scope grows so the target keeps tracking the moving goal.
• Burnup Forecast (green, dashed extension) — projected continuation of the Burnup line from today through the resolved end date, using the same throughput and growth assumptions as the burndown Forecast. Ends at the resolved Scope at the projected completion point.

The two views are stacked on the same axis so a planner can read whichever framing they prefer; teams that report progress as "completed" read the burnup, teams that report it as "remaining" read the burndown.

Optional series

• Scope Growth Projection (purple, dashed) — extrapolation of the historical add-rate forward in time. Shown when growth detection is enabled.
• Forecast (green dashed by default; multi-strategy comparisons add coloured variants) — the projected curve from Delivery Forecast. The chart marks the projected end date with a P label.
• Confidence band — shaded area around the forecast line, optional. Two modes: Historical variability (width derives from the team's own velocity, scope-change, and estimate-vs-actual stddevs combined via root-sum-of-squares) and Monte Carlo (sampled from ~600 randomised runs, P10–P85 envelope). Both fan out on the time axis — left edge finishes earlier, right edge finishes later.

Sprint markers

A Sprint Markers checkbox. When on, vertical lines mark sprint starts (solid) and ends (dashed). A second checkbox Include Completed Sprints toggles whether closed sprints are also marked. In Program All mode the checkbox is disabled because cadences differ across projects.

Per-user filter

When the team has multiple assignees a filter row appears with chips: All + one chip per assignee. Switching to a single user shows that user's scope, remaining, and ideal-burndown lines only. Single-select — clicking the same chip again returns to All.

Period Breakdown table

Below the chart, a collapsible table titled [Period] Breakdown (Weekly Breakdown, Monthly Breakdown, etc.). One row per period.

Columns

• Period — the bucket label (e.g., May 10).
• Issues — count of issues with scope events in the bucket; click to expand.
• Added — story points added in the bucket through new issue creation or estimate increase. Green when non-zero.
• Burned — points removed from scope through estimate decrease or removal. Grey.
• Completed — cumulative points completed by end of bucket; monotonically increasing unless retroactive scope changes.

Expansion

Clicking a period expands it to list every issue that contributed to that period. Each row shows the issue's key (linked), summary, current assignee with avatar, status pill, and which event-type categories it appears under. An issue can show in Added and Completed in the same period if it was created and finished in the same bucket.

Scope events

Three kinds of event drive the timeline:

• Creation — issue is created with a non-zero estimate; that estimate joins scope on the create date.
• Estimate change — storyPoints (or originalEstimate in time mode) is edited; the delta is added to scope on the change date.
• Status to "removed" — issue transitions to a removed-set status (Cancelled, Won't Do, Won't Fix, Rejected, Duplicate, Invalid). Its current estimate is subtracted on the transition date.

The Scope line is the cumulative running sum of these signed deltas. The events come from Jira's changelog so they are tied to wall-clock time, not sprint boundaries.

Scope growth detection and "never finishes"

The forecast card's Scope Growth Rate readout is computed by:

1. Bucketing all creation and removal events by ISO week.
2. Computing the net points added per week (issues created minus issues removed, by points).
3. Converting to points per sprint using the project's sprintLengthWeeks.

Two failure-mode signals fall out of this:

• When scope growth ≥ velocity and the simulation never empties the queue, the forecast returns the explicit never finishes state. This is preferred over an infinite date so the user gets an actionable signal.
• When the growth rate is high but velocity is higher, the forecast still completes but the projected end may sit further out than the no growth projection.

Cross-cutting modes and settings

• Estimation mode — points mode reads storyPoints; time mode reads originalEstimate ÷ 3600 for hours (or ÷ 28800 for 8-hour days). The chart's Y-axis label and table units adapt.
• Sprint mode on/off — when off, sprint markers are hidden and the Earliest sprint start / Latest sprint end options for the date cards are removed. The forecast still works using configured throughput.
• Include backlog — controls whether unscheduled backlog issues participate in scope. Backlog inclusion can change scope growth rates noticeably if the backlog was populated upfront rather than over time.
• Program All mode — sprint markers are forced off; the forecast returns the latest end across all per-project forecasts.

Empty / error states

• Loading — while issues are still streaming in.
• Configure a JQL filter in Settings — when the project has no JQL configured.
• No issues found for JQL filter — when the JQL returns zero rows.
• No timeline data available — when issues exist but no scope events fall inside the visible window.

How the numbers are computed

• Burndown / Remaining / Scope lines — see ALGORITHMS section 1 (Delivery Forecast) and the Burndown Chart Data subsection of the Appendix.
• Scope Growth Rate — section 3 (Scope Growth Detection).
• Forecast curve / P50 / P85 — section 1 plus section 2 (Monte Carlo Delivery Confidence) for the band shading.
• Scope event reconstruction — Appendix → Scope Trajectory subsection.
• Period bucketing / partial-week proration — Appendix → Date and Timeline Math and ISO Week Conversion.

Effects on other parts of the app

• The Scope row in the Dashboard's Project Statistics table reads the same growth rate and change % shown on the stat card.
• The Delivery Forecast card on the Dashboard uses the same forecast utility and respects the Scope growth selector value chosen here. Toggling growth on the Scope tab changes the Dashboard's projected end immediately.
• The Sprint Risks engine's Mid-sprint scope creep detector uses the same scope event timeline and the same SCOPE_CREEP_WARN_PCT threshold.
• Changes to Velocity sprint count persist into project config and propagate to every other forecast view.