Jira, Jira Premium and Rovo are good at what they were built for. Project Commander was built for a question none of them ask. This is a plain account of where each one is strong, taken from Atlassian's own documentation for its products and from Project Commander's own screens. Sources are listed at the end.
Project Commander is an add-on for Jira, not a replacement for it. It installs into your own Jira site, reads what you already keep there, and leaves Jira as the place the work lives. Jira Premium and Rovo are the only Atlassian products it stands in for — Premium’s planning and capacity features, and Rovo’s delivery reporting. Nothing on this page is an argument for replacing Jira, because Project Commander cannot be used without it.
Every delivery team eventually gets asked the same thing: will this be delivered by the date, with the people we actually have — and if not, where does it break?
Jira records the work and reports what happened. Jira Premium lays the work out on a timeline across teams and lets you type in who is available. Rovo reads what is in Jira and writes it back as summaries, digests and follow-ups. Project Commander takes the work, the real people and the date, does the arithmetic, and tells you whether the plan holds — sprint by sprint, person by person, with odds — and keeps telling you as the plan moves. With or without sprints: a project with Sprint Mode off is read from its Issue filter and judged week by week, so a Kanban or date-planned team gets the same answer.
Jira Plans builds the roadmap. Project Commander tells you whether it will hold. Plenty of teams keep the roadmap in Plans and use Project Commander to pressure-test it, sprint by sprint and person by person. They are not in competition for the same job.
| Built to answer | |
|---|---|
| Jira | What is the work, who has it, what state is it in, what got done last sprint? |
| Jira Premium — Plans | When is each piece scheduled, across which teams, and does the sprint's typed capacity hold it? |
| Jira Premium — Capacity view | How have I allocated each person's time this week, at the epic level, and who did I over-allocate? |
| Rovo | What does all of this say, summarised — what is overdue, stalled or due soon? |
| Project Commander | Can this be delivered by the date with the people we have — and if not, where, by how much, and what do we do? |
1. It plans with the people you actually have. Capacity is worked out per person — hours a week, or points a sprint, how much of their time this project gets, booked time off, company holidays — and added up to the sprint. Teams that do not run sprints get the same arithmetic: with Sprint Mode off in the project's settings, a Kanban or date-planned team's work is read from its Issue filter and weighed week by week against capacity for a period of a length you choose. Jira Premium's Plans uses one number per team per sprint, shared out equally, with no time off. Its new Capacity view, generally available since 27 July 2026 on Premium and Enterprise, takes an allocation you type in for each person — a percentage, hours or days against a fixed forty-hour week — and it plans epics and higher-level work items only, not the stories and tasks in the sprint. Project Commander asks for one figure per person — hours a week, or points a sprint — and works out the rest itself: it subtracts their booked time off, company holidays and their availability, applies the share of their time this project gets, and weighs what is left against the stories and tasks actually assigned to them. Tell it once that your senior engineer is on leave for the middle week of the sprint and every number moves. In one line: Jira lets you allocate people's capacity; Project Commander tests the work actually assigned to them against the capacity they really have.
2. Every sprint carries a verdict, and it means what it says. Deliverable, Tight or Overcommitted, with the load as a percentage, on every sprint row. For the sprint running now, it compares only the work still left against only the capacity still ahead — the capacity still ahead is worked out from the weeks actually left in it, so somebody away for the rest of the sprint adds nothing. Plans shows a bar that turns red when work exceeds the typed number; there is no percentage, no verdict, and no allowance for time already used.
3. It forecasts a finish date, with odds, not a wish. The forecast walks the plan sprint by sprint, carries overflow forward, and names the person who becomes the bottleneck. Then it runs the plan 250 times against the team's real variation and reports the probability of hitting the target and a likely-finish range. Plans schedules work into sprints and shows where it lands — a placement, not a probability. Rovo produces no date at all.
4. It will tell you "never." If scope is growing faster than the team clears it, the forecast says the work does not finish — not a comfortable date two quarters out. And it counts only the capacity you have actually planned: work that does not fit the sprints you have reads "Does not fit the plan", with how much does not fit and about how many more sprints it would take, rather than a date somewhere past the last one. No Atlassian product makes that call.
5. It sees scope creep as it happens. From Jira's own change history it rebuilds what was added, re-estimated or removed after the plan was agreed — per sprint and over time — and flags a running sprint that has quietly grown past its commitment. Plans shows the plan as it is today. Jira's burnup shows scope rising, without saying what rose or when.
6. It finds the dependencies that break a plan, not just draws them. A task blocked by work that is not scheduled until later. Two tasks that block each other, so neither can ever start. A sub-task due after its parent. Each is an alert with a way to resolve it. Plans draws dependency lines and turns one red when the lead-in item is late, and its auto-scheduler does recognise two items that block each other — by leaving them out of the schedule. Project Commander raises the circle as an alert naming both items, so someone can break it.
7. It names the data that would poison a forecast. Missing estimates, missing dates, unassigned work, items marked done with time still remaining, overdue items — forty checks in all, each from a rule. A forecast built on half-filled fields is worth nothing, so it says which fields. Plans' warnings cover date and sprint conflicts; estimates and assignment are not among them.
8. It shows you who is overloaded from the work, not from a timesheet. Per person, per sprint, against their own capacity — read from what is actually assigned to them. Across several projects, one person's shares add up and turn red past a hundred per cent. The Capacity view shows who you over-allocated by hand; it does not read the work.
9. Auto-Level rearranges the sprints so they fit — and shows you before it touches anything. When sprints are overcommitted, Auto-Level moves work between them to fit the capacity that is actually there. It orders the work so nothing is placed before what it depends on, treats each person's own capacity as a hard limit, uses only the capacity still left in the running sprint, and offers four strategies — by priority, by size, by due date, or balanced across people — over a horizon you choose. Two tasks that block each other are flagged, not skipped. The result is a preview: every sprint before and after, the change to the forecast date, and a line explaining each move that a constraint forced. Nothing is written to Jira until you accept it. Jira Premium's auto-scheduler fills the timeline for you too, and it is worth being precise about how, from Atlassian's own description. It works from one team velocity number and a head count, and assumes each person handles one story at a time. It will not touch the running sprint even when that sprint is overbooked. Work without an estimate is placed by date but left out of the capacity arithmetic. Two items that depend on each other are ignored entirely. Like Auto-Level, its result is staged rather than written straight to Jira: you preview it, accept it into the plan, then use Review changes to save the Sprint, Team and Release fields back. Each of those simplifications on its own is reasonable. Together they mean the plan it produces is very unlikely to be one you could deliver as written — the overbooked sprint stays overbooked, the person who is away is scheduled anyway, and the unestimated and circular work is quietly left out. You would still have to check every sprint by hand, which is the job you were hoping to hand over.
10. What-if you can feel. Sliders for velocity, estimates, scope and capacity; the date and the odds move as you drag. Plans keeps saved scenarios; it does not put the odds on a slider.
11. Risks with a paper trail. A register of risks and dated actions, entered by people or proposed from patterns in the numbers with the arithmetic printed underneath, with owners and response strategies, and alerts when an escalation is waiting or a review is due. Rovo's Delivery Agent writes the health check and the status update; it does not keep the register.
12. Every number is arithmetic. Nothing on any screen is inferred, sensed or guessed. No AI model is asked anything: every figure, and every sentence written around it, is worked out by the app from what is in Jira. That is the difference between a number you can defend to a steering committee and one you have to caveat.
13. No AI service, and nothing to approve. Project Commander asks no AI model anything, and it declares no address outside Atlassian that it is allowed to reach, so no project data can go to an AI vendor. For an organisation whose data-handling policy says which AI vendors may see project data — or none — there is nothing to approve. Rovo is Atlassian's own AI service: your data goes to it under Atlassian's terms, and you do not choose the provider behind it.
14. It runs inside your Jira, and nothing leaves. A Forge app: your project data stays in your Atlassian instance. Free during the beta.
Be as clear about this as about the rest.
| Project Commander | Jira | Jira Premium | Rovo | |
|---|---|---|---|---|
| Capacity per person, with time off and holidays | Yes | — | Plans: one number per team. Capacity view: typed allocation per person, fixed 40-hour week, epics and above only | — |
| Deliverable / Tight / Overcommitted on every sprint, with a percentage | Yes | — | A bar that turns red | — |
| Running sprint judged on what is left against what is left | Yes | — | — | — |
| Forecast finish date | Yes, sprint by sprint, naming the bottleneck | — | A scheduled placement | — |
| Odds of hitting the date, and a range | Yes — 250 runs | — | — | — |
| Says "never" when scope outruns the team | Yes | — | — | — |
| Scope creep rebuilt from history | Yes | Burnup shows scope rising | — | — |
| Dependency conflicts: blocked by later work, circular loops, child after parent | Yes | Links on the issue | Lines; one turns red when late; circles left out of scheduling | — |
| Missing estimates, missing dates, unassigned, done-with-time-remaining, overdue | Yes | — | Date and sprint conflicts only | Overdue, stalled, due soon |
| Who is overloaded, from assigned work | Yes, per person per sprint, and across projects | — | Capacity view: from what you typed | — |
| Rearranging work to fit capacity | Auto-Level: per-person limits, dependency order, running sprint's remaining capacity, four strategies, preview showing every sprint before and after and the change to the forecast date | — | Auto-scheduler: one team number and head count, one item per person at a time, leaves the running sprint as is, ignores circular and unestimated work; changes staged in the plan, saved to Jira on Review changes | — |
| What-if | Sliders with live odds | — | Saved scenarios | — |
| Timeline of the work, as a chart | Yes — every epic and issue as a bar, placed by the forecast, with the target date, the forecast date and the likely range on the same picture; red where it runs past the target or past a person's capacity | — | Yes — drag-and-drop cross-team timeline; a bar sits where it was dragged | — |
| Programs of several projects, shared people | Yes | — | Yes — cross-team timeline | — |
| Works with sprints and without them (Kanban, date-planned) | Yes — Sprint Mode on or off, per project | Kanban boards | Yes — timeline by date | — |
| Risk register with owners, actions, escalation alerts | Yes | — | — | Health check and status updates |
| Baselines — how the forecast has moved | Yes | — | — | — |
| AI — what it does | None; every figure is arithmetic | Rovo | Rovo | Summaries, digests, agents |
| AI provider — whose, on whose terms | None; no AI service is called | Atlassian's | Atlassian's | Atlassian's |
| Cross-team roadmap timeline | Program roll-up | Timeline view | Yes — its core strength | — |
| Runs inside Jira; data stays | Yes | — | — | — |
| Cost | Free during beta | Included | Premium tier | Paid plans |
Jira tells you what is happening. Premium lets you lay it out and type in who is available. Rovo summarises it back to you. Project Commander is the arithmetic in between — the work, the real people and the date — and tells you whether it holds, where it breaks, and what to do about it.
Atlassian documentation, as of 5 September 2026:
Project Commander: projectcommander.app — features, documentation, and the live demo.