Getting Started — Feature Guide
What this guide is for
This is the five-minute path from opening Project Commander for the first time to a screen that answers the question the whole app is built around: can this work realistically be delivered in the time and capacity we have, and if not, where is the risk?
You'll set the app up, point it at your work, tell it about your team, pick how it should forecast the finish date, and then read the three screens that show whether you're on track. Every step says exactly where the control lives so you can follow along in the app.
This guide describes Project Commander installed in your Jira site from the Atlassian Marketplace. The web app at projectcommander.app/app offers two ways in without installing anything: See Demo (the same screens on sample data — nothing stored, resets on reload) and Connect Your Own Jira (your real project, read-only — one-click authorization through your Atlassian account, no token to paste; your notes and settings stay in that browser). The installed app is the full product — team-shared data, velocity history, trends, and write-back — so to follow this guide end to end, install it from the Marketplace.
1. First launch — the setup screen
The very first time the app opens, a one-page setup screen asks the four things it needs: Project Key, Board, Issue filter, and whether work is estimated in Story Points or Time (choosing Time reveals an Hours/Days picker). Type your project key — the prefix on every issue, like AUTH — and leave the field: the app checks it against your Jira site, fills in the project's real name and the standard "everything in this project" filter, and finds the project's board for you (if the project has several boards you pick one from a short named list; if it has none you type the board number from the board's URL). A key Jira doesn't recognize is flagged immediately, next to the field. Click Add Project and you land on the Dashboard with your project's numbers.
The More options link at the bottom opens the full Add Project form on the Projects tab instead — everything you already typed carries over — for setting a target date, capacity, or sprint settings up front. On that path, every other tab stays locked and the Settings gear hidden until the project is added.
Adding more projects — the Projects tab form

Later projects are added on the Projects tab with + Add Project. The form has the same key-first help: type the key and leave the field, and the name, filter, and board fill in the same way.
Three fields are required:
- Project Key — a short uppercase id like AUTH. Checked against your Jira site as you leave the field.
- Board ID — the Jira board the app reads sprints and issues from; found automatically from the key for most projects.
- JQL Filter — the Jira query that decides which issues belong to this project; pre-filled as "everything in this project", editable for narrower slices.
Everything else is optional, with sensible defaults you can change any time:
- Name — a readable label (defaults to the key).
- Target Date — the deadline the forecast is measured against (you can also set this later on the Dashboard).
- Estimation Mode — Story Points or Time; choosing Time reveals an Hours / Days picker (one day counts as eight hours). This sets the unit every screen uses for capacity and progress.
- Story Points Field — appears in Story Points mode. Most sites can leave the default; if your site keeps story points in a different Jira field (common for company-managed projects), pick it here — the dropdown shows which fields actually hold values so the right one is easy to spot.
- Sprint Mode — on by default; turn it off to treat the project as a continuous backlog instead of sprints. The same tabs are available either way: with Sprint Mode off the Sprints tab is renamed Tasks, and Risks, Actions and What-If all remain (What-If shows its Project and All Projects views, with no Sprint sub-view).
- Sprint Capacity, Sprint Length (1–4 weeks), Velocity Lookback (how many recent sprints to average), and Capacity Mode.
Fill in the three required fields and add the project. To run more than one project, come back to this tab and add another; each project keeps its own settings. Every project row has Edit and Delete buttons.
2. Finding your way around
Once your first project is in, here's the layout:
- The tabs run across the top — Dashboard, Sprints, Scope, What-If, and the rest. Each answers a different question; this guide visits the ones a new user needs first. (They stay locked until that first project is added.)
- The project picker at the top lets you switch between projects, or choose All projects to see the whole programme rolled up into one.
- A gear at the top-right of every tab opens the global Settings panel.
3. See your work in the Sprints tab

Open the Sprints tab to see your work laid out by sprint. Each sprint is a card showing demand against capacity — how much work is in the sprint against how much the team can do — and a badge that reads Deliverable, Tight, or Overcommitted (closed sprints with everything finished read Delivered). On the sprint currently running, the stats read Remaining demand and Remaining capacity — the open work against the capacity left in the sprint's remaining days. That badge is the at-a-glance answer to "is this sprint realistic?"
Click a sprint card to expand it. You'll see the sprint goal, the per-person Team & Capacity breakdown, and the full issue table, where you can edit assignees, points, status, and dates inline.
4. Tell the app about your team's capacity

The forecast is only as good as the capacity behind it, so set your real team up on the Team & Capacity tab. Use + Add Member to add each person, then set their capacity (points per sprint, or hours per week) and their utilisation. You can also record time off (PTO) and company holidays, which the app subtracts so the forecast doesn't assume people are available when they aren't.
The number that matters most is Net capacity — what's left after utilisation and time off. That's the figure the forecast and the feasibility score on every other screen actually read.
If you run more than one project, also set each person's per-project allocation — the share of their capacity that goes to each project — in the allocation matrix on the Team & Capacity tab. Someone split 60% / 40% across two projects only contributes that share to each project's forecast, so a project whose allocations are left blank can read low or even zero capacity even though the people are set up. Enter the allocation in the same estimation mode (points or hours) the project uses. With a single project you can skip this — everyone is allocated 100% to it automatically.
5. Set the target date
Go to the Dashboard. The Target Date card (the blue one) shows the deadline everything else is measured against. Open its gear to choose how that date is set: Latest issue due date (the default — the app uses the latest due date across your unfinished issues) or Fixed date (you pick an explicit deadline). You can also set a project's target date on the Projects tab Edit form; they're the same target.
6. Choose how the finish date is forecast

Still on the Dashboard, the Delivery Forecast card shows the projected finish date for all remaining work, the on-target odds, and a likely-finish range. Open its gear to choose the two models that drive that date:
- Capacity model — how the app counts how fast the team works: Sprint capacity, Effective capacity (velocity adjusted for how much the team usually delivers versus plans), Team capacity (the sum of everyone's capacity from the Team & Capacity tab), or Velocity (a rolling average of recent sprints).
- Demand model — how the app orders the remaining work: Ignore dependencies, Respect dependencies, Resequence work, or Critical Chain only (the earliest the blocking chain alone allows).
- Scope growth — off by default; turn it on to have the forecast assume work keeps being added, either at your project's own historical rate (Average) or a rate you type (Manual).
Below the cards, open the Delivery Forecast grid to see every capacity-model-by-demand-model pairing at once — each with its finish date, its gap to target, and its on-target odds, shaded green, amber, or red. Click any cell to make that pairing drive the card above. The demand model you pick is shared with the Scope and What-If tabs, so the same choice means the same thing across all three.
7. Review the Sprints tab for problems
Now read for trouble. On the Sprints tab, look for any sprint with an Overcommitted badge — that sprint is carrying more work than the team can finish. Inside a sprint, a warning icon on an issue means it's either bigger than the whole sprint's capacity or blocked by work that sits in a later sprint (so it can't actually start on time). These are the spots most likely to slip.
8. Review the Scope tab for problems

Open the Scope tab to see whether the work is burning down fast enough to hit the target. The chart draws what's left over time against an ideal line to the target date, plus a forecast line that projects where you'll actually land; a T marks the target date and a P marks the projected finish. If the forecast line lands well past the target, or the optional Scope Growth line is climbing, you've found a real risk. The same Delivery Forecast card from the Dashboard sits here too, so the projected date matches exactly.
9. Test a plan on the What-If tab

Finally, the What-If tab is the sandbox for "what would fix this?" — nothing here touches your real Jira data. Drag the four sliders (velocity, issues estimation, scope, capacity) and watch the forecast and the cascade chart move live. Flip the panel's switch from What-If to Simulation to get the odds of finishing on time across many runs, and use the AI chat to turn a plain question like "what if we add a developer?" into slider settings. The three sub-views — Sprint, Project, and All Projects — let you test one sprint, the whole project on a weekly timeline, or every project rolled up together.
10. Where to look next
- The Dashboard's Top Open Risks widget lists the project's highest-score open risks — a fast standup-prep view.
- The Alerts tab surfaces dependency conflicts, including work blocked by something scheduled later and circular dependencies.
- The Risks tab tracks the biggest threats to delivery, with AI-suggested risks you can accept in one click.
- Each tab has its own feature guide with the full detail; this guide is just the on-ramp.