Tempo Capacity Planner (the app that was Tempo Planner) is good at what it was built for: planning people's hours across an organisation. Project Commander was built for a different question. This is a plain account of where each one is strong, taken from Tempo's own help pages and Marketplace listing 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?
Tempo Capacity Planner lets a manager plan hours for each person against work items or projects, day by day, with each person's working hours and public holidays already taken off, and — with Tempo Timesheets bought alongside it — compares the hours planned with the hours logged. Project Commander takes the work actually assigned in the sprints, 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.
| Built to answer | |
|---|---|
| Tempo Capacity Planner | How many hours is each person planned for, on what, this week and next — and is anyone planned past their hours? |
| Tempo Timesheets (sold separately) | How do the hours planned compare with the hours logged? |
| 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. 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. Tempo also works per person and takes holidays and part-time hours off through its workload and holiday schemes. The difference is what the capacity is compared with. In Tempo it is compared with hours a manager types into a plan, per day or as a total spread evenly. In Project Commander it is compared with the work actually assigned in the sprint, in the team's own unit — story points or hours — with nothing to type.
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. Tempo shows a person's planned hours against their available hours and marks the days planned past them. There is no verdict on the sprint, no percentage of the sprint's capacity, and no allowance for the part of the running sprint already gone.
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. Tempo's pages describe no finish date and no probability. A plan in Tempo ends on the day the last hours were planned.
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. Tempo does not make that call; it has no forecast to make it from.
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. Tempo shows the plan as it stands today. It does not read Jira's change history.
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. Tempo does not read dependency links.
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. Tempo warns when a person is planned past their hours. Missing estimates, missing dates and unassigned work are not among its warnings.
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. Tempo shows who is over-planned from the hours a manager entered. It does not read what is assigned to the person in the sprint.
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. Tempo has no equivalent. Over-planned hours are fixed by hand, one plan at a time, and a plan can be routed to a reviewer for approval.
10. What-if you can feel. Sliders for velocity, estimates, scope and capacity; the date and the odds move as you drag. Tempo has no what-if.
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. Tempo keeps no risk 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. Tempo's figures are arithmetic too — planned hours against available hours. The difference is what they are arithmetic about.
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. Nothing is sent at all until someone presses one of the seven places the AI can be asked from. Tempo's pages for Capacity Planner describe no AI feature.
14. It runs inside your Jira, and nothing leaves. A Forge app: your project data stays in your Atlassian instance. Free during the beta. Tempo's Marketplace listing does not say where its data is held. Ask before you assume either way.
Be as clear about this as about the rest.
Plenty of teams keep the hours plan in Tempo and use Project Commander to check whether the sprints it feeds are actually deliverable. They are not in competition for the same job.
| Project Commander | Tempo Capacity Planner | |
|---|---|---|
| Capacity per person, with time off and holidays | Yes | Yes — hours per day, workload and holiday schemes |
| Deliverable / Tight / Overcommitted on every sprint, with a percentage | Yes | Over-planned days per person |
| Running sprint judged on what is left against what is left | Yes | — |
| Forecast finish date | Yes, sprint by sprint, naming the bottleneck | — |
| 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 | — |
| Dependency conflicts: blocked by later work, circular loops, child after parent | Yes | — |
| Missing estimates, missing dates, unassigned, done-with-time-remaining, overdue | Yes | Over-planned hours only |
| Who is overloaded, from assigned work | Yes, per person per sprint, and across projects | From hours a manager planned |
| Rearranging work to fit capacity | Auto-Level: per-person limits, dependency order, running sprint's remaining capacity, four strategies, preview before anything is written | By hand; plan approval workflow |
| What-if | Sliders with live odds | — |
| Programs of several projects, shared people | Yes | Yes — many teams, shared people |
| Works with sprints and without them (Kanban, date-planned) | Yes — Sprint Mode on or off, per project | Yes — plans by the day, no sprints needed |
| Risk register with owners, actions, escalation alerts | Yes | — |
| Baselines — how the forecast has moved | Yes | — |
| Planned hours against logged hours | — | Yes, with Tempo Timesheets |
| Skills, cross-team time requests, approvals | — | Yes |
| AI provider — whose, on whose terms | Your own: Anthropic, OpenAI or Google, your own key, off until you add one | None described |
| Runs inside Jira; data stays | Yes | Not stated on the listing |
| Cost | Free during beta | Paid per user on the Marketplace; Timesheets sold separately |
Tempo tells you how each person's hours are planned, and with Timesheets how they were spent. Project Commander tells you whether the work in the sprints can be delivered by the date with those people — where it breaks, by how much, and what to do about it.
Tempo documentation and listing, as of 5 September 2026:
Project Commander: projectcommander.app — features, documentation, and the live demo.