Settings Reference

Project Commander's settings live on the tab or screen where you use them — there is no single Settings page that holds everything. This reference lists every setting grouped by where you set it, what it does, and what changes downstream when you flip it. For how a tab behaves overall, see that tab's own guide.

Projects tab — Add / Edit project

Most of what shapes a project is set per project. Open the Projects tab and click + Add Project, or Edit on a row. On Add, a Project Key, Board ID, and JQL filter are required; on Edit only the key is required.

• Project Key (required) — the Jira project key, e.g. DEMO.
• Name (optional) — a display name; it defaults to the key when left blank.
• Board ID (required) — a free-text field (placeholder e.g. 134) for the Jira board the app reads sprints and backlog from. It is typed in by hand; there is no auto-detection and no "Detected" label.
• JQL filter — a Jira query (e.g. project = "AUTH") that defines which issues belong to the project. Required on Add; clearable on Edit. It scopes the Dashboard, Scope, Alerts, Epics, and Trends tabs; it does not scope the Sprints tab or Auto-Level, which read everything on the board.
• Target date — a date picker for the deadline the project is measured against. (How the target is resolved — latest issue due date vs a fixed date — is chosen on the Dashboard's Target Date card, not here.)

Estimation mode — the master switch

Story Points or Time (default Story Points). This is the master switch for the whole project: it controls which Jira field is read, every number, every unit label, and where capacity comes from.

• Story Points reads Jira's Story Points field; you set how much the team can take per sprint.
• Time reads Jira's Remaining Estimate (hours); capacity is calculated from the team setup (hours per person, minus weekends, holidays, and time off).

What changes when you switch from Story Points to Time:

• Sprint headers relabel from "pts" to "hrs" (or "days"), and the numbers change entirely — a sprint at "40 pts" might read "320 hrs". A sprint that was green in points can turn red in hours if the team's hour capacity doesn't match the point limit.
• Issue rows show each issue's size in hours/days; the Remaining Estimate column becomes the meaningful one.
• On the Dashboard, the On Pace? and Delivery Forecast cards recompute on time; the forecast verdict can flip because capacity now comes from calculated team hours instead of the manual point limit. Progress usually stays similar (both sides scale together).
• The Scope tab's demand-vs-capacity chart changes its Y-axis to Hours/Days and redraws the capacity line from team hours.
• What-If runs on hours; the sliders still work the same (they are percentages).
• Auto-Level sizes issues in hours, so packing can shift an issue or two between sprints.
• The Missing-Estimates alert flips field: it flags issues without story points in Story Points mode, and issues without time estimates in Time mode. The Done-with-Remaining-Work alert mainly surfaces in Time mode.
• Dependencies and sprint risk badges do not change — they are about sprint order and blocker status, not estimates.

Time unit

Appears only when estimation mode is Time. Hours or Days (default Hours). Days simply divides every hours figure by 8 for display (an 8-hour day); the underlying data never changes. "Scope +96 hrs" reads "Scope +12 days".

Sprint mode

A checkbox, on by default. On: the app reads sprints and the backlog from the board. Off: a flat backlog with no sprints, and the sprint-only fields below (Sprint capacity, Sprint length, Velocity lookback, Capacity mode) are hidden on the form.

What turning Sprint mode off does:

• The Sprints tab and the sprint-based What-If view become unavailable; Auto-Level, velocity tracking, scope-creep detection, and sprint risk badges all stop (they need sprints).
• The Dashboard and forecast still work, but on issue due dates instead of sprint boundaries; the Delivery Forecast card offers only the Team-capacity and Effective-capacity models (Sprint capacity and Velocity drop out).
• Alerts and the Epics tab keep working.

Sprint capacity

A number, default 40, labelled pts/sprint (or hrs/sprint / days/sprint in Time mode). The project's default capacity per sprint, used as the fallback when a sprint isn't given its own capacity. Raising it turns over-capacity sprints green, lets Auto-Level pack more per sprint (fewer overflow sprints), and can improve the Delivery Forecast. There is no separate per-user number on this form — per-person limits come from the Team & Capacity tab.

Sprint length

Weeks, 1 to 4, default 2. Dates newly created sprints and feeds Auto-Level's overflow sprints. Velocity is normalised to a weekly rate, so lengthening sprints lowers the apparent weekly rate (same work over more weeks) and pushes the projected date later. The Sprint capacity number does not auto-scale with length — adjust it yourself if you change length.

Velocity lookback

3, 5, 8, or 10 recent closed sprints, default 5, averaged for velocity and Effective-capacity figures. Fewer sprints make the average more reactive (one unusual sprint counts for more) and widen the What-If simulation's spread.

Capacity mode

Sprint limit or Per-user capacity (default Sprint limit). Shown only when Sprint mode is on. Sprint limit applies one capacity number to the whole sprint. Per-user capacity gives each member their own per-sprint limit and flags individuals when overloaded. ("Auto / velocity" is not an option.)

What switching to Per-user capacity does:

• Sprint headers replace the single team capacity bar with a per-person breakdown; a sprint can be green overall yet show one person in red.
• Over-capacity highlighting turns red when any single person is over their limit, even if the team total has room.
• Auto-Level runs a different balancing pass (per-person workload instead of sprint totals), which can move an issue because its assignee is overloaded.

Settings dialog (the gear)

The gear at the top-right of the tab bar opens app-wide preferences (not per-project).

• Tab visibility — four checkboxes show or hide optional tabs: Epics, Plan What-If, Actions, and Risks. Visibility only; no calculation changes.
• Read-only mode — a checkbox (off by default) that hides every write control across the app: drag-drop, start/complete/create/delete sprint, sync due dates, sprint date and name editing, locking, and capacity editing. Auto-Level still previews as a dry run, but Accept is blocked. All viewing, analytics, charts, and What-If sliders keep working.
• Display columns — which columns appear in the sprint issue tables. The default set is Key, Summary, Assignee, Story Points. About 20 standard columns are offered (Type, Key, Summary, Assignee, Reporter, Priority, Status, Story Points, Original/Remaining Estimate, Time Spent, Sprint, Start/Due Date, Epic, Epic Link, Parent, Subtasks, Linked Issues, Labels); type 2+ characters to search any Jira field and add it, or add a free-text custom column. Display only.
• AI features — a Provider dropdown (None (AI off) by default, Anthropic (Claude), OpenAI (ChatGPT), Google (Gemini)), an API Key field (stored in the app's encrypted Atlassian Forge storage, used only when an AI feature runs), and a Model picker that is required once a provider is chosen — it reads Select a model… and saving without one shows an error. Available models: Anthropic — Claude Fable 5, Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5; OpenAI — GPT-5.5, GPT-5.4, GPT-5.4 Mini, GPT-4o Mini; Google — Gemini 3.5 Flash, Gemini 2.5 Pro, Gemini 2.5 Flash, Gemini 2.5 Flash Lite. With a provider configured, an AI Insights chat appears on the Dashboard and AI Review appears on Auto-Level.

Dashboard tab

• Include backlog — a checkbox at the top-left of the Dashboard (in sprint mode), off by default. Unchecked, the dashboard counts only sprint issues plus done issues; checked, it adds everything matching the project's JQL filter. Turning it on raises remaining-work totals and can lower the Progress percentage.
• On Pace? card (gear) — an Include — All Done, not only planned checkbox, and a Pace measure radio with three options: Auto (recommended) (the default), Timeline-based, and Schedule-based.
• Delivery Forecast card (gear) — three controls, all shared project settings: the same controls appear on the Scope and What-If forecast cards, and changing one anywhere updates all three.
  • Capacity model — with sprints on: Sprint capacity, Effective capacity, Team capacity, Velocity. With sprints off: only Team capacity and Effective capacity.
  • Demand model — Ignore dependencies, Respect dependencies, Critical Chain only, Resequence work. (When Critical Chain only is chosen, the Capacity model control is replaced by a note that Critical Chain ignores team capacity, and the Scope-growth control is hidden.)
  • Scope growth method — a checkbox that turns it on, plus an Average / Manual dropdown; Manual reveals a per-week growth-rate number. Off by default.
• Target Date card (gear) — a Date source radio: Latest issue due date (the default) or Fixed date (which reveals a date picker).
• Progress card — display only: the percent complete plus "done" and "remaining" totals; it shows an over-delivered note (capped at 100%) if scope shrank below completed work.
• The Delivery Forecast grid below the cards is a display, not a setting: it lays out every Capacity model (rows) against every Demand model (columns) so you can compare every pairing's finish date at once. Clicking a cell just sets the two dropdowns above to that pairing.
• Delivery Forecast detail — the See detail below link on the forecast card opens a breakdown table whose rows carry radio buttons; choosing one sets which projection source the forecast date is read from. It is remembered with the project.
• AI Insights — a chat panel that appears only when an AI provider is configured in the gear dialog.

Sprints tab

• Per-sprint capacity — each sprint card's capacity dropdown (in the Team & Capacity section of the card): Project default (the project's Sprint capacity), Team capacity (sum of members' capacities), Effective capacity (N%) (team capacity × historical efficiency; the live percentage shows in the option, and it appears only when there is velocity history), or Custom (a number for just that sprint; reads Custom for sprint in per-user mode). Each sprint's choice is independent.
• Per-user capacity — in Per-user capacity mode, type a number into a member's capacity cell in the sprint's By-User table to override just that person for just that sprint; right-click the cell to reset it to default.
• Locks — a per-issue lock pins the issue during Auto-Level (its size still counts against the sprint, but it never moves) and blocks dragging; a per-sprint lock freezes the whole sprint (nothing moves in or out, and it rejects drops). Auto-Level only rearranges unlocked issues in unlocked sprints.
• Sprint dates — each sprint's start and end dates are editable inline. Sync Due Dates pushes the sprint's end date onto the due date of every issue in that sprint (a lock does not exempt an issue from this sync).
• Closed sprints — a Closed sprints dropdown on the Sprints toolbar sets how much sprint history is loaded and shown alongside the open sprints (in date order): Hidden (the default), the last 5, the last 20, or all closed sprints. Remembered with the project.
• Auto-Level — click Auto-Level to enter a dry-run mode, then choose:
  • Strategy — Priority (highest priority first), Size (smallest first), Due Date (soonest due first), or Balanced (spreads work evenly, placing large issues into the sprint where each fits best). All four respect dependencies (a blocker lands no later than what it blocks), keep locked issues and sprints in place, honour per-sprint limits, and place a single oversized issue (bigger than a sprint) into its own holding area to decide where it goes.
  • Horizon — Next sprint, Next 2, Next 3, or All sprints.
  • Include backlog issues — a checkbox to pull backlog work into the leveling.
  • Compare All — runs Priority, Size, Due Date, and Balanced at once and shows them side by side with delivery forecasts.
  • After a run: Undo Changes (revert but stay in the mode), Accept (save the moves to Jira), AI Review (only when AI is configured), and Exit (revert and leave). Auto-Level is available to everyone — it is not a premium-gated feature.
• Scope creep — on an active sprint, a badge reads Scope: +N pts vs start (or −N / ±0) and expands to list the issues added or removed since the sprint started, with the original and current totals.
• Sprint risk badges — future sprints show a dependency-health badge: No Risk (all earlier-sprint blockers are done), Medium Risk (a blocker is in progress), or High Risk (a blocker hasn't started). Independent of estimates and capacity.
• Dependencies — a Dependencies button opens a map with three tabs: All (every blocking relationship), Cross-Sprint (only links spanning different sprints), and Violations (blockers that finish after the work they block starts).

Team & Capacity tab

This is where the team is set up; it drives capacity in Time mode and provides reference data in Story Points mode.

• Team members — each row carries a capacity per week (points/week or hours/week, default 40 hrs), a utilisation % (added members default to 80; the project default is 100), time-off and holiday deductions, a net capacity, demand, and a status badge. Members are picked up automatically when you assign issues to them, or added with + Add Member (which asks only for a name). The last column is Remove — it deletes the member and unassigns their open issues in Jira; there is no inactive state. Capacity is stored per ISO week; Populate weeks bulk-fills a span at the member's current rate.
• Time off — click days on the calendar to mark it (a plain click selects one day, Ctrl+click toggles a day, Shift+click selects a range), then set the hours-per-day (Full / Half / 2 / 1) and an optional reason; it reduces that person's available capacity.
• Company holidays — add a date with a name and an optional Yearly (repeats-yearly) flag; holidays reduce everyone's capacity for sprints that span them. There are no built-in US/UK preset lists.
• Status badges — a member reads Overloaded above about 115% of capacity, Optimal from about 90%, Available from about 60%, Underloaded below that, and a neutral dash when they have neither capacity nor work.

Scope tab

• Delivery Forecast card — the same shared Capacity model, Demand model, and Scope growth method controls as the Dashboard's card (changing them here changes them everywhere).
• Include backlog — a separate toggle on the Scope timeline chart (not inside the forecast card).
• Confidence band — a chart control for the forecast's uncertainty band (off by default).
• Start date card — a Date source radio that anchors the timeline's left edge: Fixed (reveals a date picker), Earliest start, Earliest due, or Earliest sprint start.
• Target date card — a date-source radio: Fixed date, Latest due date, or Latest sprint end.

What-If tab

The What-If tab is a sandbox: its sliders are scenario inputs that reset when you leave, not saved settings — but its forecast card carries the same shared settings as the Dashboard.

• What-If / Simulation toggle — switches each sub-view between the deterministic What-If sliders and a Monte Carlo Simulation.
• Sub-view toggle — Sprint, Project, or All Projects, shown only when more than one is available (Sprint needs sprint mode and sprints; All Projects needs more than one project).
• Sliders (What-If mode) — Velocity, Issue estimation, Scope, and Capacity, each a −50% … +50% swing from the current plan, with a Reset all to baseline button. The slider positions are transient — they return to baseline when you leave the tab.
• Uncertainty ranges (Simulation mode) — each of the four variables becomes a low–high range instead of a single value.
• Sprint-view checkboxes — the Sprint sub-view adds Cascade overflow, Include backlog, and Breakdown by user above the sliders.
• Forecast card (gear) — in the Sprint and Project sub-views this is the same shared card as the Dashboard (Capacity model, Demand model, Scope growth all shared). In the All Projects sub-view only the Demand model is shared; the Capacity model and Scope-growth override there are local to that view.

Risks tab

The Risks tab is optional — it is shown by the Risks checkbox in the gear dialog and only when Sprint mode is on. It carries two saved settings of its own, in a small preferences bar across the top of the tab (not in the gear):

• AI risk suggestions — on by default. When off, the AI-generated risk suggestions are hidden; the underlying risk detectors still run, only the AI wording is skipped.
• Auto-close risks when all mitigation actions complete — off by default. When on, a risk closes by itself the moment its last linked action is marked done, with no prompt.

The tab's other controls — the source, status, scope, and strategy filters and the sort dropdown — are view filters that reset when the app reloads, not saved settings.

Other tabs

These tabs have no saved settings of their own — their only setting is the show/hide checkbox in the gear dialog (and most also need Sprint mode on). Any filters or sorting on them are view controls that reset when the app reloads.

• Actions — shown or hidden by the Actions checkbox in the gear dialog (Sprint mode must be on). Its status, scope, originator, and assignee filters, its sort, and its group collapsing all reset on reload. It does follow the Risks tab's Auto-close setting, since completing an action can close its risk.
• Epics — shown or hidden by the Epics tab-visibility checkbox in the gear dialog; the JQL filter and estimation mode drive its numbers. Visibility only.
• Trends — a historical-trend tab driven by the JQL filter, estimation mode, time unit, and Include backlog; it can be hidden along with the other optional tabs. Not affected by capacity settings.

Reference — capacity precedence

When several capacity sources could apply to a sprint, the app resolves them in order; the first one that is set wins.

In Sprint limit mode (per sprint):

• a Custom number typed on the sprint card, else
• Effective capacity (if selected and efficiency data exists), else
• Team capacity (if selected), else
• the Project default (the project's Sprint capacity, default 40).

In Per-user capacity mode (per member, per sprint):

• a per-user override typed in the member's cell, else
• the member's own configured capacity from the Team & Capacity tab (optionally efficiency-adjusted when Effective capacity is in play), else
• the project default split across the sprint's assignees.

Effective capacity is available in both capacity modes whenever historical efficiency data exists — it is not limited to one mode.

Reference — which settings drive which features

• Estimation mode and Time unit touch nearly everything: sprint headers, all four Dashboard cards, the Scope chart axes, What-If, Auto-Level sizing, velocity units, the Missing-Estimates alert, and scope-creep units. They do not change dependencies or sprint risk badges.
• Capacity mode drives sprint-header layout (one bar vs per-person), what "over capacity" means (team total vs any individual), and which Auto-Level pass runs.
• Sprint capacity, per-sprint capacity choice, per-user overrides, and the team setup all feed the resolved capacity used by sprint headers, Auto-Level bin sizes, the Delivery Forecast, and the Scope capacity line.
• Sprint mode gates the Sprints tab, Auto-Level, velocity, scope-creep, sprint risk badges, the Capacity-mode control, and the sprint-based What-If view.
• Velocity lookback and Sprint length feed velocity, the projected completion date, Effective capacity, and (for length) new-sprint dating.
• Include backlog and the JQL filter decide which issues are in scope for the Dashboard, Scope, Alerts, Epics, and Trends — but never the Sprints tab or Auto-Level.
• Display columns, the tab-visibility checkboxes, Read-only mode, and the AI provider affect what you see or what you can change, not the underlying numbers.