Can You Just Ask Jira When a Project Will Finish?

Project Commander is an add-on for Jira, not a replacement for it. It installs into your own Jira site, reads the projects, sprints, issues, people and links you already keep there, and leaves Jira as the place the work lives. The only things it stands in for are the planning and capacity features of Jira Premium and the delivery reporting of Rovo — see the side-by-side comparison.

"When will this finish?" is the question every delivery manager gets asked, and typing it into a box is the fastest way to ask it. It is also the fastest way to get a confident wrong answer. A question box is only worth having if you can repeat what it tells you to the people who funded the work — and that depends entirely on where the numbers in the answer came from.

The problem with asking a model

Hand a language model your project data and ask when the work finishes, and it will answer. It will sound fluent and specific, and it will produce a date. What it will not do is arithmetic you can check. Ask the same question twice and the date can move. Ask it next week with one issue added and the reasoning can change shape entirely. Nobody can tell you which of the numbers in the paragraph came from your board and which came from the model's sense of what a plausible answer looks like.

That is a fatal flaw for a planning answer, because a planning answer has to survive being challenged. If a stakeholder asks "where does the 14th of December come from?", "the AI said so" ends the conversation badly.

What a question box has to do instead

The fix is to separate the two jobs that get bundled together. Reading the question is a language job. Producing the figures is an arithmetic job. A model is good at the first and must never be trusted with the second.

So the useful shape is: the words place the question, the engine answers it, and the same engine that draws the cards on your screens produces every number. A model, if you have one set up, only helps read an awkwardly worded question and write the figures into a paragraph. Then one more rule does the real work — every number in that paragraph is checked against the figures the engine produced, and a sentence naming a figure the engine never produced is not shown at all.

The test to apply to any tool that offers you a question box: can you open a screen and find the number the answer gave you? If you cannot, you are being handed an opinion with a decimal point in it.

The questions worth asking

Once the answers come from an engine rather than a model, the list of things worth typing gets long, because each question is arithmetic on data your Jira already holds:

• "When will this finish, and what are the odds of hitting the 31st of March?" — the forecast, and the probability of the target, run across hundreds of simulations rather than a single optimistic line.
• "What would one more person do?" — a what-if that changes nothing in Jira, that says plainly it is about a team that does not exist, and that can be put down again.
• "Which sprints are overcommitted?" — one row per sprint, demand against the capacity still ahead of it.
• "How much has the scope grown since the 1st of September?" — what arrived after the plan was set, and what went into sprints after they started.
• "What needs my attention?" — the risks ranked worst first, rather than a wall of everything.
• "Why is the date what it is?" — the plan broken into the factors that produced it, each with the figure that makes it one.
• "Where would pushing pay?" — which of pace, issue size, scope or capacity moves the finish furthest, worked out rather than guessed.

The questions it should refuse

There is a second list, and a tool that answers it is one to distrust. Ask whether the team seems blocked, what a comment implies, or whether a description sounds risky, and the only possible answer is a judgement drawn from reading words. Nobody can check it — not you, not the person who wrote the comment, not the stakeholder you repeat it to.

A good answer to those questions is a refusal that says why, and offers the answerable version instead. Everything else the box tells you can be verified by opening a sprint card; that property is worth more than a longer list of things it will talk about.

Answers and actions are different things

An answer is safe. An action is not. So the moment a question turns into "move CLAIM-42 into Sprint 9", the rules change: the tool should say exactly what it is about to do, wait for a deliberate second press, and afterwards read the issue back out of Jira to confirm the change really happened, rather than assuming it worked because nothing threw an error. And it should hand you the sentence that undoes it.

Project Commander's Ask panel works this way. It opens from the tab bar over whichever tab you are on, so the figures that prompted your question are still in front of you. Every number is worked out by the app, by the same code the cards on every tab are drawn from, so the same question always gives the same answer — and it answers with no AI set up at all. A model, when you configure one with your own key, only reads awkward questions and writes the figures into a paragraph; any paragraph naming a figure the app did not produce is dropped. Questions about what people meant are refused, with the answerable question offered in their place. Changes to Jira take two presses and are read back afterwards.

Related reading: How to forecast a Jira delivery date you can trust · What-if planning in Jira · All Project Commander features