ActivityTimeline is good at what it was built for: a day-by-day timeline of who is scheduled on what, with timesheets in the same app. Project Commander was built for a different question. This is a plain account of where each one is strong, taken from ActivityTimeline's own website 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?
ActivityTimeline lays each person out on a timeline, day by day, shows the hours their remaining estimates put on each working day against their hours, takes off holidays, days off, sick leave and part-time schedules, and lets them log time against the same tasks. 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 | |
|---|---|
| ActivityTimeline — Planner | Who is scheduled on what, day by day, and is anyone over their hours on a given day? |
| ActivityTimeline — Timesheets and Reports | What did each person log, was it approved, and how did it compare with the plan? |
| 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. ActivityTimeline also works per person and takes off holidays, leave and part-time hours. Its workload indicator puts the hours from remaining estimates onto each working day. Project Commander works per sprint, in the team's own unit — story points or hours — and compares the whole sprint's assigned work with the whole sprint's capacity.
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. ActivityTimeline colours a person's day when the hours on it exceed their hours. 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. ActivityTimeline's pages describe no finish date and no probability. Its "resource forecasting" means who will be free when, not when the work will finish.
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. ActivityTimeline 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. ActivityTimeline shows the schedule 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. ActivityTimeline 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. ActivityTimeline warns when a day is over its 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. ActivityTimeline reads remaining estimates, which is a fair start, but by the day. Project Commander reads what is assigned to the person in each sprint and compares it with that sprint's capacity for that person.
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. ActivityTimeline's own comparison pages list automated resource balancing across people. Its pages do not describe a preview of the plan before and after, dependency order, or the running sprint's remaining capacity as a limit.
10. What-if you can feel. Sliders for velocity, estimates, scope and capacity; the date and the odds move as you drag. ActivityTimeline 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. ActivityTimeline 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. ActivityTimeline's figures are arithmetic too. The difference is what they are arithmetic about: hours by the day, not sprints.
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. ActivityTimeline's pages 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. ActivityTimeline's 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 day-by-day schedule and the timesheets in ActivityTimeline and use Project Commander to check whether the sprints are actually deliverable. They are not in competition for the same job.
| Project Commander | ActivityTimeline | |
|---|---|---|
| Capacity per person, with time off and holidays | Yes | Yes — hours per day, leave types, part-time |
| Deliverable / Tight / Overcommitted on every sprint, with a percentage | Yes | Over-hours 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-hours days only |
| Who is overloaded, from assigned work | Yes, per person per sprint, and across projects | From remaining estimates, by the day |
| Rearranging work to fit capacity | Auto-Level: per-person limits, dependency order, running sprint's remaining capacity, four strategies, preview before anything is written | Drag and drop; automated balancing listed on its comparison pages |
| What-if | Sliders with live odds | — |
| Programs of several projects, shared people | Yes | Yes — teams across projects |
| Works with sprints and without them (Kanban, date-planned) | Yes — Sprint Mode on or off, per project | Yes — schedules by the day, no sprints needed |
| Risk register with owners, actions, escalation alerts | Yes | — |
| Baselines — how the forecast has moved | Yes | — |
| Timesheets, approvals, planned against logged hours | — | Yes — its core strength |
| 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 | $2.50 a user a month at 11 to 100 users, from its pricing page |
ActivityTimeline tells you who is scheduled on what each day and what they logged. 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.
ActivityTimeline pages and listing, as of 5 September 2026:
Project Commander: projectcommander.app — features, documentation, and the live demo.