Project Commander

I built this after watching the same thing happen on project after project: the plan says one date, everyone privately knows it will not hold, and nobody can show why until it is too late to do anything. Jira has the answer in it already — the sprints, the estimates, who is on what, the links between issues — it just never does the arithmetic. So Project Commander does it: remaining work against the capacity the team actually has between now and the target date, and a finish date with a range rather than a single optimistic day. It is an add-on that reads your Jira and leaves the work where it lives. Free during the beta. Happy to answer anything, and I would genuinely like to hear where your own plans go wrong — it is usually the part nobody measures.

Jira deadline risk is a pain point teams usually only notice too late. Surfacing whether a project will actually hit its date, rather than just showing raw sprint progress, sounds like the more actionable view.

A finish date with a range instead of one optimistic day is exactly what stakeholders need to hear early. Where my own plans go wrong: almost never the work itself, but waiting — on a client's approval, a partner's signature, someone else's API. That time rarely appears as an issue in Jira, so the forecast looks fine until it isn't. Can Project Commander account for "blocked / waiting on external" time? And how is the range calculated — from the team's past velocity, or from the spread in estimates?

Showing the delivery date as a confidence range instead of a single date is the right call, since a point estimate always looks more certain than it is. Does the What-If scenario reuse the same capacity model as the main forecast, or is it a separate calculation?

A forecast expressed as a confidence range is the right call - a single date invites false precision. I am curious how it treats drift from the original plan. Does the model learn each person's real throughput from Jira's time tracking, or does it stay anchored to the configured velocity and story points? And do team calendars - holidays, part-time allocations, on-call rotation - feed the capacity model, or is that still something a PM encodes by hand each sprint?

Native Forge so the forecast stays inside the Jira site is the right constraint for teams that cannot send issue data out. Scope creep rebuilt from Jira's own change history is more useful than a manual changelog, but I would want to know whether a bulk edit or an automation rule counts as creep the same way a human field change does. When Auto-Level rebalances an overloaded sprint, does that write the new assignments back into Jira, or is it only a suggestion you still apply by hand?

Rebuilding scope creep from Jira's own change history is the feature I'd show a stakeholder first, because it turns 'the date moved' into an actual list of what was added. Does the confidence range widen automatically when estimates are missing on a chunk of the backlog?