Project Commander Docs ← Back to site

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 (no Board ID when the Sprint Mode box is unticked); on Edit only the key is required. Every setting a project has lives in ONE place, the project's own record, the one this form creates (since 2026-09-04). The gears on the Dashboard, Scope and What-If cards, the Sprints tab's capacity controls and this form all change that same record, so no two screens can hold two different values for one project; until then the gadget kept a second copy of every setting and the two drifted apart.

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.

What changes when you switch from Story Points to Time:

Story Points Field

Appears only when estimation mode is Story Points. Jira sites store story points in different custom fields: team-managed projects use "Story point estimate" (the app's default), while company-managed projects use a separate "Story Points" field whose internal number varies per site. If the app reads the wrong one, every issue looks unestimated and demand reads zero. This dropdown picks the field the app reads story points from — and writes them to, for inline edits — for this project.

If the configured field misses estimates that another story-points field holds, the Dashboard and Alerts tab show a notice with the evidence (which field, how many issues) and a button to this form. The notice appears at most once per session and can be dismissed.

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".

Remaining Work

Appears only when estimation mode is Time (in Story Points mode the choice would change nothing). Picks the ONE way every screen — and the delivery forecast engine — counts unfinished work (ruling 2026-07-15):

Whichever you pick applies everywhere at once: the Dashboard Progress card's "remaining", every Delivery forecast card's "Remaining" line, the Scope tab's Burned & Remaining card, demand-vs-capacity figures, the weekly digest, and the forecast simulation itself — so the same remaining number appears on every surface, and switching the setting moves them all together. On the committed basis the forecast is slightly more conservative (logged time on unfinished tasks doesn't shorten the work); on the live basis it credits logged progress. Burned % and Remaining % always sum to 100 either way.

Sprint mode

A checkbox at the bottom of the form, on by default. On: the app reads sprints and the backlog from the board. Off: a flat list of the issues the JQL filter finds, with no sprints and no board needed; the Velocity Lookback field is renamed Throughput Lookback. Sprint capacity and Sprint length stay, renamed Capacity (per period) and Period Length — a project without sprints still plans in periods, and until 2026-09-01 those two fields vanished while the Scope chart and the Epics budget went on using the stored number anyway.

What turning Sprint mode off does:

Sprint capacity

A number, default 40, labelled Sprint Capacity (pts/sprint) (or hrs/sprint / days/sprint in Time mode). With Sprint mode off the field reads Capacity and pts/period (or hrs/period / days/period), and the number is the capacity of each planning period. The capacity of every sprint that has not been given a number of its own — the same meaning in both kinds of project since 2026-09-01. A time project used to ignore this field and use a fixed six hours a day per person instead; that rate is gone, along with the separate Capacity limit setting it came from. Changing the project's unit converts the number: hours to days divides by eight, days to hours multiplies by eight, and a line under the field says what it became. Switching between story points and time clears it, because the two cannot be converted into one another. On this form a field left blank or set to 0 is saved as 40. 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.

Hours per story point

A number, default 4, shown only when Estimation Mode is Time. Some issues carry a story-point estimate and no time estimate; to show those on a screen measured in time, the app multiplies the points by this number. Until 2026-09-01 it appeared in no field at all and was two different numbers at once — 4 on the Can We Deliver row, the Scope tab's Demand vs Capacity chart and the Epics budget, 8 on the Critical Chain demand model and the schedule behind it. It is one number now, and everything reads it. A 0 saved through Edit is honoured: story-point-estimated work then counts as no time at all.

Sprint length

Weeks, 1 to 4, default 2. With Sprint mode off the field reads Period Length and says how long one planning period is — what the Capacity number above is worth, what the Delivery Forecast card steps through, and what the Demand vs Capacity chart on the Scope tab draws one block per. 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

Any whole number from 1 to 10 recent closed sprints, default 5, typed into the Use last … sprints box, averaged for velocity and Effective team capacity figures. The same setting is written from two other places: the Use last … sprints box behind the Delivery Forecast card's gear on the Dashboard, Scope and What-If tabs (shown only while the card's Capacity model is Velocity, or Throughput without sprints), and the Lookback dropdown (Last 3 / 5 / 8 / 10 sprints) under the Velocity button on the Sprints tab toolbar. With Sprint Mode off the form's field reads Throughput Lookback and counts periods. Fewer sprints make the average more reactive (one unusual sprint counts for more) and widen the What-If simulation's spread.

Settings dialog (the gear)

The gear at the top-right of the tab bar opens the Project Commander Settings dialog, saved with the Save Configuration button at its foot. Everything in it except The Alerts tab section is saved on the project selected at the top right, like the settings on the Add / Edit Project form, so two projects can differ. The Alerts tab section is saved for you alone, as you click. A line under the heading names that project — Settings for IBTF — IBT F6 Time sprints. Everything below but the Alerts section is saved on this project. — because the project picker sits behind the dialog; with no project selected it says so instead.

When the save goes through, Saved! appears beside the button and the dialog closes. When the store or the Jira account refuses it, the dialog stays open, what was typed stays as typed, nothing on the tab bar changes, and a red line beside the button reads The settings could not be saved and nothing was changed. Try again. The line stays until the next save.

Directly below the Provider dropdown a blue notice shows whether or not AI is switched on. Its first paragraph says that once an API key is saved, sprint data (issue summaries, assignee names, sprint names and story points) is sent to the chosen provider, that nothing is sent without a key, and links to the privacy policy. Its second names the three addresses the app is permitted to reach outside Atlassian - api.anthropic.com, api.openai.com and generativelanguage.googleapis.com - and explains that Atlassian lists all three whether or not the feature is used - on the screen Jira shows while the app is being installed, and in Atlassian Administration under Connected apps - because an app declares what it is permitted to reach up front rather than when it reaches it. The app contacts one of them only once a provider is chosen here and your own key is saved.

Below the Model picker, once a provider is chosen, sits Hide people's names from the AI (off by default). With it on, everyone on the team is sent as "Person A", "Person B" and so on. Every number still goes - who has how much work, and who is over capacity - so the answer is just as useful, and the real names come back into the answer you read. The list of who is who is never sent, so the AI provider cannot work it out.

Each model is given its own room to answer. The models that think before they answer, or that simply write more, are given more of it: Claude Fable 5 and Opus 4.8, every GPT-5, and every Gemini but Flash Lite. Before 11 September 2026 every model of a provider shared one allowance, and three of the twelve ran out of it and answered half way - Claude Opus 4.8, the Gemini Flash models and GPT-5.5.

Dashboard tab

Sprints tab

Team & Capacity tab

This is where the team is set up. It is where Team capacity and Effective team capacity come from — two of the three choices in the Capacity source control inside each sprint card's Team section on the Sprints tab — and it works the same way in both kinds of project. The third choice, the project's Sprint capacity number on Projects → Edit, also applies in both.

Scope tab

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.

Risks tab

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

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. Any filters or sorting on them are view controls that reset when the app reloads.

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.

Per sprint:

Per person, per sprint:

A person's row is never a share of the sprint's own number, on any source. Effective team capacity is offered whenever a closed sprint gives a usable efficiency reading.

Reference — which settings drive which features

© 2026 Project Commander · projectcommander.app · Support · Privacy · Security · Terms