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.

1. First launch — add your first project

Add Project form — Project Key, Board ID, and JQL Filter (required), plus Name, Target Date, Estimation Mode, Sprint Capacity, Sprint Length, Velocity Lookback, Capacity Mode, and the Sprint Mode toggle

The very first time the app opens, it lands you straight on the Projects tab — no questionnaire to click through. Click + Add Project to open the registration form. Until you've added one project, every other tab is locked and the Settings gear is hidden; if you click another tab you get a short note telling you to add a project first. The moment you add a project, everything unlocks and fills with that project's data.

Three fields are required:

Project Key — a short uppercase id like AUTH.
Board ID — the Jira board the app reads sprints and issues from.
JQL Filter — the Jira query that decides which issues belong to this project.

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.
Sprint Mode — on by default; turn it off to treat the project as a continuous backlog instead of sprints.
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

Sprints tab — toolbar plus the active sprint card with its Demand vs Capacity header and issue table

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

Team & Capacity tab — period selector, member table with capacity and status, and the totals row

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

Delivery Forecast grid — every capacity model (rows) against every demand model (columns), each cell shaded by its on-target odds, with the Critical Chain floor as a merged column and Earliest / Latest flags

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

Scope tab — the burndown chart with ideal line, forecast line, target marker, and the Delivery Forecast card

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

What-If tab — sliders for velocity, estimation, scope, and capacity, with the Delivery Forecast card and cascade chart

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.