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.
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.
| 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 hours this week, 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 or points a sprint, how much of their time this project gets, booked time off, company holidays — and added up to the sprint. Jira Premium's Plans uses one number per team per sprint, shared out equally, with no time off. Its new Capacity view takes hours you type in against a fixed forty-hour week. Neither knows that your senior engineer is on leave for the middle week of the sprint. Project Commander does, because you told it once and every number moved.
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 — half a sprint gone means half the capacity gone. 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 two thousand 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. 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; it does not detect a circle.
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 — thirteen kinds of alert 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. And it writes the Sprint, Team and Release fields directly. Each of those on its own is a reasonable simplification. 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. Where AI is switched on, it explains and suggests, and never produces a figure — a guard in the code checks every quantity an answer states against the data it was given. That is the difference between a number you can defend to a steering committee and one you have to caveat.
13. Your own AI provider, your own rules. AI in Project Commander is off until you add a key of your own, and you choose the AI provider — Anthropic, OpenAI or Google — on the Settings screen. There is no AI service of Project Commander's sitting in the middle: your request goes from your Jira to the provider you picked, under the account and terms you already hold with them, and Project Commander never stores, sees or resells what goes to it. Nothing is sent at all until someone presses one of the seven places the AI can be asked from; there is no always-on assistant reading the project. For an organisation whose data-handling policy says which AI vendors may see project data — or none — that is the difference between a tool you can switch on and one you cannot. 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.
Plenty of teams keep the roadmap in Plans and use Project Commander to pressure-test whether it holds. They are not in competition for the same job.
Summarising a work item, writing the standup digest, drafting the stakeholder update, chasing stale tickets, breaking a story into tasks: Rovo does these well, and the Delivery Agent's health check is a fair list of what is overdue and stalled.
Every one of those reads what Jira already holds and rewrites it. Nothing in Rovo computes capacity, models demand against it, or produces a date with odds — and Atlassian does not claim it does. Rovo tells you the plan is late once it is late. Project Commander tells you three sprints ahead that it cannot be met, and by how much.
| Project Commander | Jira | Jira Premium | Rovo | |
|---|---|---|---|---|
| Capacity per person, with time off and holidays | Yes | — | Plans: one number per team. Capacity view: typed hours per person, fixed 40-hour week | — |
| 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 — two thousand 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 | — |
| 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 before anything is written | — | 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, writes fields directly | — |
| What-if | Sliders with live odds | — | Saved scenarios | — |
| Programs of several projects, shared people | Yes | — | Yes — cross-team timeline | — |
| Risk register with owners, actions, escalation alerts | Yes | — | — | Health check and status updates |
| Baselines — how the forecast has moved | Yes | — | — | — |
| AI — what it does | Explains and suggests; never produces a number | Rovo | Rovo | Summaries, digests, agents |
| AI provider — whose, on whose terms | Your own: Anthropic, OpenAI or Google, your own key, off until you add one, sent only when asked | 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 3 September 2026:
Project Commander: projectcommander.app — features, documentation, and the live demo.