Every setting, what it does, and the full chain of effects
Two choices: Points or Time.
Points — The app uses Jira's Story Points field to measure everything. You manually decide how many points your team can handle per sprint.
Time — The app uses Jira's Remaining Estimate field (hours logged against issues). Capacity is automatically calculated from your team setup — how many hours each person works, minus weekends, holidays, and time off.
Sprint headers:
Issue rows in sprints:
Dashboard:
Demand vs. Capacity chart:
What-If:
Auto-Level:
Alerts:
Velocity:
Dependencies and Risk Badges:
Only appears when Estimation Mode is Time. Two choices: Hours or Days.
Hours — All numbers shown in hours (e.g., "160 hrs capacity").
Days — Converts everything using an 8-hour workday (e.g., "20 days capacity").
Two choices: Per Sprint or Per User. Only shown when Sprint Mode is on.
Per Sprint — One capacity number for the whole team per sprint.
Per User — Each team member has their own capacity limit per sprint.
Sprint headers:
Over-capacity highlighting:
Dashboard:
Auto-Level:
Feasibility analysis:
A number field. The label changes depending on Capacity Mode:
This is the fallback — you can override it per sprint or per person directly in the Sprints tab. See Capacity Precedence Hierarchy for the full override chain.
Sprint headers:
Dashboard:
Auto-Level:
What-If:
A checkbox (default: on).
Tabs that disappear:
Features that stop working:
What still works:
Which Jira Scrum board to connect to. Often auto-detected from the page context (shows "Detected" label).
A text field for a Jira query (e.g., project = PROJ AND type = Story).
Tabs that show new data: Dashboard, Scope, Alerts, Demand vs. Capacity, Trends, Epics
Tabs NOT affected: Sprints (shows all issues from the board), Auto-Level (operates on all sprint/backlog issues)
If the JQL is invalid: An error message appears in the UI. Tabs that depend on JQL issues show empty or error state. Other tabs keep working.
A checkbox (default: on). Only visible when Sprint Mode is on and Board ID is set.
When enabled, backlog issues are included in all views (Alerts, Deliverability, Scope, Team, Sprints).
Practical guidance: Turn this off when you only want to track committed/planned work. Turn it on for the full picture of everything that needs to get done.
A checkbox (default: on).
Enable to show the Epics tab for high-level epic progress tracking, forecasts, and dependencies.
The What-If tab has a Sprint / Project toggle at the top.
Both views share the same sliders, Monte Carlo simulation, cascade chart, and AI analysis. No separate setting is needed — the toggle is built into the tab.
A checkbox (default: off).
When enabled, your Jira data is never modified. Drag-drop, sprint actions, and date syncing are disabled.
Sprint actions — all blocked: Start Sprint, Complete Sprint, Delete Sprint, Create Sprint, Sync Due Dates, Sprint date editing, Sprint name/goal editing.
Issue management — all blocked: Drag-drop between sprints, Drag-drop to backlog, Locking/unlocking issues and sprints.
Auto-Level: Preview (dry run) still works. "Accept" is blocked — changes can't be saved to Jira.
Capacity limit editing in sprint headers is disabled.
A collapsible section within Settings.
A dropdown that changes what the "Done X%" number in sprint headers represents. Options depend on your Estimation Mode.
| Mode | Option | Example |
|---|---|---|
| Points | Points (Done / Total) | 30 pts done out of 50 pts = "Done 60%" |
| Time | Estimate (Remaining / Original) | 6 hrs remaining of 15 hrs original = "Done 60%" |
| Time | Work Ratio | 4 hrs spent with 6 hrs remaining = "Done 40%" |
When you switch Estimation Mode, the Progress Indicator automatically resets to the default for that mode.
Only affects the sprint header progress display. Dashboard cards, feasibility charts, capacity calculations, and auto-level are not affected.
A dropdown: 1 week, 2 weeks (default), 3 weeks, 4 weeks.
Length of new sprints created by Auto-Level.
Auto-Level overflow sprints: Each new sprint spans 3 weeks instead of 2. Fewer new sprints may be needed.
Velocity normalization: Velocity is normalized to "per week." Changing from 2 to 3 weeks makes the weekly rate look 33% lower (same total work / more weeks), pushing the projected date later.
Important: Your "Capacity limit per sprint" does NOT auto-scale with sprint length. If you change sprint length, consider adjusting your capacity limit proportionally (e.g., 40 for 2 weeks → 60 for 3 weeks).
A dropdown: Last 3, Last 5 (default), Last 8, or Last 10 sprints.
Number of completed sprints used to calculate team velocity for projections.
Select which columns to show in the issue tables.
20 standard columns: Type, Key, Summary, Assignee, Reporter, Priority, Status, Story Points, Original Estimate, Remaining Estimate, Time Spent, Sprint, Start Date, Due Date, Epic, Epic Link, Parent, Subtasks, Linked Issues, Labels
Default enabled: Key, Summary, Assignee, Story Points
You can also search for Jira custom fields and add them as columns, or add custom text columns by typing a name and clicking "+ Add as custom column".
This only affects the issue table display — no impact on calculations.
| Setting | Description |
|---|---|
| AI Provider | Dropdown: Anthropic (Claude), OpenAI (ChatGPT), Google (Gemini) |
| API Key | Text field for your chosen provider's API key. Show/Hide toggle. |
| Model (optional) | Pick a specific model or leave as Default. |
Available models by provider:
When configured, an "AI Insights" section appears on the Dashboard with a chat input where you can ask questions about your project data.
Configured in the Demand vs. Capacity tab. This is where you set up your team. It directly drives capacity calculations in Time Mode and provides reference data in Points Mode.
Each member has:
| Field | Description |
|---|---|
| Name | Display name (matched to Jira assignees) |
| Hours per day | How many hours they work per day (used in Time Mode) |
| Utilization | Percentage of time spent on project work (e.g., 80% means 20% is meetings/overhead) |
| Points per sprint | How many points they typically deliver (used in Points Mode) |
| Active toggle | Inactive members are excluded from all capacity calculations |
In Time Mode, for each sprint:
For each active member:
Available hours = (hours per day) × (workdays in sprint)
minus holidays, minus time off
× (utilization %)
Sprint capacity = sum of all members' available hours
If Time Unit is Days, divide by 8.
In Points Mode, for each sprint:
For each active member:
Available points = (points per sprint) × (workdays available / total sprint workdays)
× (utilization %)
Sprint capacity = sum of all members' available points
A list of dates the whole team has off.
| Field | Description |
|---|---|
| Name | e.g., "New Year's Day" |
| Date | The holiday date |
| Repeats yearly | If checked, applies every year on that date |
Presets available for US holidays and UK holidays (8 holidays each).
Individual time off per team member (vacation, sick leave, etc.).
| Field | Description |
|---|---|
| Member | Which person |
| Date range | Start and end dates |
| Reason | Optional (defaults to "Time Off") |
Set directly in the sprint view, not in the Settings panel.
Click the capacity number in any sprint header to edit it.
See Capacity Precedence Hierarchy for the full override chain.
In Per User capacity mode, click any user's capacity bar to set a custom limit for that person in that sprint. Overrides the global "Capacity limit per user" for just that person in just that sprint.
Click the lock icon next to any issue.
Visual: A red lock icon appears. The issue row becomes slightly faded/ghosted. The drag handle is disabled.
During Auto-Level: The issue stays exactly where it is. Its size still counts against the sprint's capacity, reducing room for other issues. Other unlocked issues may get moved out to make room.
Click the lock icon on a sprint header.
Visual: Sprint card gets an amber/yellow left border and light yellow background. A red lock icon appears in the header.
During Auto-Level: Every issue in this sprint becomes locked automatically. No issues can move in or out. The sprint is completely frozen. Auto-Level operates only on unlocked sprints.
Each sprint has Start Date and End Date fields (editable inline). These determine:
Auto-Level uses an inline toolbar-based workflow. Click the Auto-Level button to enter auto-level mode, then pick a strategy from the dropdown.
"Puts the highest-priority issues first, filling sprints front to back"
Sorts all issues by Jira priority (Highest → Lowest). Fills Sprint 1 first, then Sprint 2, etc.
Best for: Teams that want to ensure high-priority items ship first.
Trade-off: Early sprints may contain a mix of large and small issues.
"Puts the smallest issues first, filling sprints front to back"
Sorts by estimate (smallest first). Packs many small items into early sprints.
Best for: Teams that want to maximize the number of items completed early.
Trade-off: High-priority but large items may end up in later sprints.
"Puts the soonest-due issues first, filling sprints front to back"
Sorts by due date (earliest deadline first). Issues with no due date go last.
Best for: Teams working against external deadlines.
Trade-off: A tight-deadline, low-priority issue will be placed before a high-priority issue with no deadline.
"Spreads work evenly — places large issues first, picking the sprint where each one fits best based on remaining room and workload"
Produces the most even distribution across sprints.
Best for: Teams that want predictable, consistent sprint loads.
Trade-off: High-priority items may not all end up in the earliest sprints.
Only appears when velocity data exists and Capacity Mode is Per Sprint. This is not a sorting strategy — it's a capacity adjustment option. When selected, it adjusts each sprint's capacity based on what the team has historically achieved. Selecting this disables the strategy selector and runs with priority ordering by default.
Best for: Teams with enough sprint history to have reliable velocity data.
Trade-off: If recent velocity was unusually low, the algorithm becomes overly conservative.
Below the strategies, separated by a divider. Runs Priority, Size, Due Date, and Balanced all at once and shows results side by side with delivery forecasts. Pick the one that best fits your situation.
What all strategies have in common:
Three buttons appear:
The Dashboard has four cards plus an optional AI Insights section.
"Of the work due by today, how much is done?"
Looks at all issues with due dates on or before today. Compares completed work to planned work.
Has a checkbox: "Include all Done, not only planned" — when checked, includes all completed work (even work not due yet) in the "done" total.
Affected by: Estimation Mode, Include Backlog, JQL Filter
"Can the team finish all remaining work by the target date?"
A combined card that shows both the on-time assessment and the projected completion date. Compares total remaining demand against total remaining capacity through the target date.
Includes a Forecast Method selector with radio buttons:
The available methods depend on what data exists (velocity data, sprint dates). The card automatically selects the best available method.
Status indicators:
Affected by: Every capacity setting, Estimation Mode, Include Backlog, Target Date, Velocity Lookback, Sprint Length, Forecast Method
"The deadline you are measuring against."
Two choices:
This date is the reference point for the Delivery Forecast. Changing it moves the goalpost but doesn't affect calculations.
"Overall percentage of work completed across all issues in scope."
Affected by: Estimation Mode, Include Backlog, JQL Filter
Future sprints show colored badges based on dependency health:
Not affected by: Estimation Mode, capacity settings, or limits. Purely about dependency relationships and blocker status.
Four sliders for what-if analysis:
| Slider | Range | What it simulates |
|---|---|---|
| Velocity | Slower → Faster | Team working at different speeds |
| Issues estimation | Smaller → Larger | Issues taking more or less effort |
| Scope | Less → More | Scope growing or shrinking |
| Capacity | Less → More | Having fewer or more resources |
The chart, feasibility score, and confidence percentage all update in real time. Each slider adjusts a percentage from the baseline.
| Setting | Description |
|---|---|
| Period Selection | Analysis time range: one week, two weeks, one month, three months, one year, or full project timeline |
| Demand Positioning | How issue work is spread: on due date only, spread evenly from start to due date, or by a specific date field |
| Assignee Filtering | Filter the analysis to specific team members using assignee chips |
| Visible Stats | Toggle: Demand, Capacity, Time Spent, Buffer, Feasibility Score, Confidence |
| Visible Chart Lines | Toggle: Period Capacity, Period Demand, Period Time Spent, Cumulative Capacity, Cumulative Demand, Cumulative Time Spent, Scope, Completion % |
For active sprints, the app automatically tracks:
An expandable panel lists every issue added or removed mid-sprint, with dates.
Units change with Estimation Mode: "Scope +12 pts" becomes "Scope +96 hrs." The percentage stays the same.
Click "Dependencies" button to open a modal with three tabs:
Issue-level warnings. Settings affect which issues are in scope, not the alert logic itself.
| # | Alert | Description |
|---|---|---|
| 1 | Done with Remaining Work | Issues marked done but still have remaining estimate. More visible in Time Mode. |
| 2 | Overdue | Past due date and not done. |
| 3 | Dependency Conflicts | Blocked by an issue that finishes too late. |
| 4 | Child After Parent | Parent issue timeline conflicts with children. |
| 5 | Missing Dates | Issues without start date and/or due date. |
| 6 | Missing Estimates | In Points mode: flags issues without story points. In Time mode: flags issues without time estimates. Switching modes can dramatically change the alert count. |
| 7 | Circular Dependencies | Dependency loops detected. |
| License Type | Access |
|---|---|
| Commercial | Full feature access |
| Evaluation | Trial with limited premium features |
| Community | Free tier |
| None | No license |
The premium-gated feature is Auto-Level. Without a license, you can view all analytics and manage sprints manually. The Auto-Level button shows: "This feature requires a premium license."
How settings depend on and affect each other:
ESTIMATION MODE (Points / Time) <-- the master switch
|
|-- determines --> which Jira field is read (Story Points vs Remaining Estimate)
|-- determines --> unit labels everywhere (pts / hrs / days)
|-- gates ------> TIME UNIT dropdown (only visible in Time mode)
|-- gates ------> PROGRESS INDICATOR options (different choices per mode)
|-- feeds ------> Sprint header numbers (demand, capacity, remaining)
|-- feeds ------> All 4 Dashboard cards
|-- feeds ------> Demand vs. Capacity chart axes & data
|-- feeds ------> Risk simulation inputs (What-If + What-If (Project view))
|-- feeds ------> Auto-Level issue sizing
|-- feeds ------> Velocity storage units
|-- feeds ------> Alerts ("missing estimates" checks a different field per mode)
|-- feeds ------> Scope creep unit display
|
+-- does NOT affect --> Dependencies, Risk Badges (sprint order, not estimates)
CAPACITY MODE (Per Sprint / Per User)
|
|-- gates ------> CAPACITY LIMIT field label ("per sprint" vs "per user")
|-- determines --> what "over capacity" means (team total vs individual person)
|-- determines --> which Auto-Level algorithm runs
|-- determines --> sprint header layout (single bar vs per-person breakdown)
|-- determines --> dashboard over-limit count meaning (sprints vs person-violations)
|-- gates ------> Effective velocity option visibility (Per Sprint only)
CAPACITY (see Capacity Precedence Hierarchy)
|
|-- feeds ------> Sprint headers (demand vs capacity display, color)
|-- feeds ------> Auto-Level bin sizes
|-- feeds ------> Dashboard Delivery Forecast and over-limit count
|-- feeds ------> Feasibility chart capacity line
|-- feeds ------> Risk simulation baseline capacity
TEAM CONFIG (hours, utilization, holidays, time off, active status)
|
+-- feeds ------> Calculated capacity per sprint
|-- feeds --> Sprint headers (when limit is "Team capacity")
|-- feeds --> Demand vs. Capacity chart
|-- feeds --> Delivery Forecast card
|-- feeds --> Risk simulation baseline
+-- feeds --> Auto-Level bin sizes
SPRINT MODE (on/off)
|
|-- gates ------> Sprints tab visibility
|-- gates ------> Auto-Level availability
|-- gates ------> Velocity tracking
|-- gates ------> Scope creep detection
|-- gates ------> Sprint risk badges
|-- gates ------> PLAN REVIEW checkbox visibility in Settings
+-- gates ------> CAPACITY MODE radio visibility in Settings
VELOCITY LOOKBACK (3 / 5 / 8 / 10 sprints)
|
+-- feeds ------> Velocity average
|-- feeds --> Delivery Forecast card projected date
|-- feeds --> Effective velocity option in Auto-Level
+-- feeds --> Risk simulation confidence / Monte Carlo variance
SPRINT LENGTH (1-4 weeks)
|
|-- feeds ------> Velocity normalization (pts/week = completed / weeks)
|-- feeds ------> New sprint date ranges created by Auto-Level
+-- feeds ------> Delivery Forecast weekly throughput calculation
INCLUDE BACKLOG (on/off)
|
+-- feeds ------> Which issues are in scope for:
|-- Dashboard demand totals
|-- Feasibility total demand
|-- Forecast remaining work
+-- Alerts issue set
JQL FILTER (query string)
|
+-- feeds ------> Scope, Alerts, Trends, Feasibility tabs
| (NOT the Sprints tab or Auto-Level)
DISPLAY-ONLY (no calculation impact):
|-- Columns ----------> which columns in issue table
|-- Epics toggle -----> show/hide Epics tab
|-- What-If (Project view) toggle > show/hide What-If (Project view) tab
|-- Read-only Mode ----> disable all Jira writes
+-- AI Provider/Key ---> enable AI features (Dashboard Insights, What-If AI Chat, etc.)
Capacity has multiple layers. The app resolves the effective capacity for each sprint using this priority order (first match wins):
For each sprint:
1. Per-sprint manual override
(user clicked the capacity number and typed a number)
→ Use that exact number
2. Per-sprint "Effective velocity"
(user selected effective velocity in the sprint header dropdown)
→ Use the historical efficiency-adjusted capacity
3. Per-sprint "Team capacity"
(user clicked the capacity number and selected "Team capacity")
→ Use the calculated team capacity for this sprint
4. Settings default
(nothing set for this sprint)
→ Use the "Capacity limit per sprint" from Settings (default: 40)
For each person in each sprint:
1. Per-sprint total override divided by assignee count
(if a per-sprint manual number is set, divide it evenly)
→ Use (sprint limit / number of assignees)
2. Per-sprint "Team capacity" per-member capacity
(if sprint is set to "Team capacity")
→ Use this member's calculated capacity from team config
3. Per-user per-sprint override
(user clicked this person's capacity bar and typed a number)
→ Use that number
4. Global per-user default
(nothing set)
→ Use the "Capacity limit per user" from Settings (default: 20)
| Setting | What it changes |
|---|---|
| Estimation Mode | Switches all numbers between story points and time. The Jira field read changes from Story Points to Remaining Estimate. |
| Time Unit | In Time mode, switches between hours and days. Pure display conversion (divides by 8). |
| Capacity Mode | Per Sprint: one capacity bar for the team. Per User: individual bars per assignee. |
| Capacity Limit per Sprint | Sets the fallback capacity number shown. A per-sprint override or Team capacity replaces it. |
| Capacity Limit per User | In Per User mode, sets each person's default capacity bar length. |
| Per-sprint override | Clicking the capacity number and typing a value replaces the global default for that one sprint. |
| Per-sprint "Team capacity" | Replaces the number with calculated team capacity. Updates dynamically if team settings change. |
| Per-sprint "Effective velocity" | Adjusts capacity to match historical delivery efficiency. |
| Per-user per-sprint override | In Per User mode, overrides capacity for a specific person in a specific sprint. |
| Progress Indicator | Changes what the "Done X%" number means. |
| Team config | Indirectly changes capacity when the sprint is set to "Team capacity." |
What determines the color: Green when demand is under capacity, amber when close (80–99%), red when over. In Per User mode, red when any single person is overloaded.
| Setting | What it changes |
|---|---|
| Capacity Mode | Routes to a completely different algorithm. Per Sprint distributes by sprint totals. Per User balances per-person workload. |
| Estimation Mode | Changes how issue size is measured (story points vs remaining estimate). |
| Time Unit | In Time mode, determines the divisor for issue sizing and capacity. |
| Capacity Limits | The default "bin size" for each sprint. Higher limit = fewer overflow sprints. |
| Per-sprint overrides | Override the bin size for specific sprints. |
| Strategy | Changes the sorting order of issues before packing. |
| Effective velocity | Adjusts sprint capacities based on historical team efficiency. |
| Velocity Lookback | Controls how many past sprints feed the velocity calculation. |
| Sprint Length | Determines the date span of overflow sprints and velocity normalization. |
| Locked Issues | Stay in their current sprint. Size counts against capacity. |
| Locked Sprints | Completely frozen. No issues enter or leave. |
| Team config | Indirectly changes capacity when sprints use "Team capacity." |
| Read-only Mode | Preview works. "Accept" is blocked. |
| License | Auto-Level requires a commercial license. |
| Setting | What it changes |
|---|---|
| Estimation Mode | Switches which field measures "done" work. |
| Time Unit | Changes unit labels. |
| Include Backlog | Backlog issues with due dates are included in "planned by now" total. |
| JQL Filter | Only filtered issues are evaluated. |
Not affected by: Capacity settings, team config, velocity, sprint length.
| Setting | What it changes |
|---|---|
| Estimation Mode | Switches remaining work from story points to hours/days. Can flip the answer. |
| Time Unit | Changes numbers shown. |
| Capacity Limit per Sprint | In Points mode, this is the capacity used to project future output. |
| Team config | In Time mode, directly determines projected capacity. |
| Sprint Length | Affects how capacity is projected per week. |
| Include Backlog | Turning off removes unscheduled work from remaining demand. |
| Target Date | The deadline being measured against. |
| Velocity Lookback | Projected date from averaging throughput across past sprints. Also editable inline within the card when the velocity method is selected. |
| Forecast Method | Radio buttons within the card to switch between velocity-based (actual throughput) and sprint-capacity-based forecasts. Available methods depend on what data exists. |
| Setting | What it changes |
|---|---|
| Estimation Mode | Determines what's being measured (story points vs time estimates). |
| Include Backlog | Backlog items increase the denominator. |
| JQL Filter | Only filtered issues count. |
| Setting | What it changes |
|---|---|
| Estimation Mode | Changes which "Missing Estimates" alert fires. Can dramatically change the alert count. |
| Include Backlog | When off, backlog issues excluded from all alert checks. |
| JQL Filter | Only filtered issues are checked. |
| Sprint Mode | Some alerts only fire when sprint data is available. |
Not affected by: Capacity settings, team config, velocity.
Shows historical trend data calculated from issues matching your JQL filter.
| Setting | What it changes |
|---|---|
| JQL Filter | Determines which issues are included in trend calculations. |
| Estimation Mode | Changes whether trends are measured in story points or time. |
| Time Unit | In Time mode, changes the unit scale on trend charts. |
| Include Backlog | When on, backlog issues are included in trend data. |
| Sprint Mode | Some trend metrics rely on sprint completion data when available. |
Not affected by: Capacity settings, team config, velocity lookback. Trends track issue data over time, not capacity planning.
Which settings affect which features. Read across a row to see everywhere a setting has impact. Read down a column to see everything that controls a feature.
Sprint Auto OnPlan Deliv Prog- Feasi- Risk Plan Alerts Scope Risk Deps Epics Velo- Drag Sprint AI Scope/
Headers Level UntNow Forec ress bility Sens Review Creep Badge Modal city Drop Action Chat Forecast
------ ----- ------ ------ ----- ------ ----- ------ ----- ----- ----- ----- ----- ----- ----- ------ ---- --------
Estimation Mode X X X X X X X X X X X X X X X
Time Unit X X X X X X X X X X X X X X
Capacity Mode X X X X X
Capacity Limit (sprint) X X X X X X
Capacity Limit (user) X X X
Per-sprint overrides X X X X X
Team config (hrs/util/etc) X X X X X X X X
Progress Indicator X
Sprint Mode X X X X X X X X X X X X
Velocity Lookback X X X X X
Sprint Length X X X X X X
Include Backlog X X X X X X
JQL Filter X X X X X
Locked Issues X X X
Locked Sprints X X X
Read-only Mode X X X
Epics toggle X
What-If (Project view) toggle X
Columns (display only)
AI Provider / Key X
License X
Reading the matrix: