When the Jira board says done: how managers check what really moved
A product manager we spoke to described a ticket she sees every sprint. It is worth two or three points. It moves through In progress, Code review and QA in three days and lands in her UAT column on day four. She opens it, tries it against the acceptance criteria, and it fails. Back it goes, all the way to the start.
Her team plans a two-week sprint at ten points and only loads seven or eight. The spare two or three points are not for surprises. They are for this: work that looked finished on the board and was not.
Her read on why: moving a ticket is how people show they are moving, especially when they work remotely. When the board is the only place a manager can see effort, the board becomes the place people perform it.
This article is for managers in that position. Jira is very good at what it does. It is just answering a different question from the one you are asking.
What the board actually tells you
A Jira board answers "where does each ticket sit right now?" Every column change is a person dragging a card or a rule firing. That is useful and it is a claim, the same way "almost done" in a standup is a claim.
The question a manager usually has is different: "what actually got done today, and can I trust it?" The board can't answer that on its own, because a card in QA looks the same whether the code behind it is merged and tested or still sitting on someone's laptop.
So the gap is not Jira's fault, and swapping trackers will not close it. ClickUp, Asana or Linear would show you the same card in the same column. The gap is between where a ticket says it is and where the work behind it actually is.
Five checks you can add inside Jira
You can close part of that gap without any new tool.
1. Write "done" down, per column. Most teams define Done. Few define what "ready for QA" or "ready for UAT" means. One line per column is enough: "QA means the pull request is merged to the staging branch and the change is on the test environment." When the rule is written, a ticket that skips it is easy to spot and easy to talk about.
2. Connect your code host. If your code is on GitHub, the GitHub for Jira app shows branches, commits and pull requests on each issue, as long as the issue key is in the branch name, commit message or pull request title. A ticket in QA with no merged pull request on it is the first thing to look at.
3. Put a rule on the transition. Jira lets admins add conditions to a workflow step, so a ticket can't move to a column until something is true. Even a light rule, like requiring a linked pull request before QA, changes behaviour more than a reminder in a meeting does.
4. Let the code move the card. Jira Automation can move an issue when a pull request is merged. When the column changes because the code changed, the board stops being something people have to remember to update, and stops being something they can update early.
5. Look at bounces, not just velocity. Count how often tickets come back from QA or UAT. A team that finishes eight points with no bounces is in better shape than one that finishes ten points and reopens four. The bounce rate is the number that tells you whether the board is honest.
These five checks make the board more truthful. They do not tell you what happened today across the whole team, including the work that never had a ticket.
The part the board never shows
Plenty of real work happens off the board: the support question that took the afternoon, the review someone did for a teammate, the design change that lives in Figma, the client call. And plenty of board movement says nothing about the day: a card can sit in In progress for a week while someone is stuck, and the board looks exactly the same on day one and day five.
That is why most teams on Jira still run a standup. The standup is the human layer: what I did, what's next, what's blocking me. The problem is that it is spoken, it is gone by lunch, and it is just as much a claim as the board is.
Where a daily report fits next to Jira
The way we think about it at Eodly is that the board and the check-in are both claims, and the work is the evidence. A good end-of-day report puts the three next to each other.
Here is how Eodly works today. Each person on the team gets one short check-in message in Slack, Telegram or Discord: what they got done, what's next, what's in the way. Eodly compares those answers with what actually moved in GitHub and Linear, and sends the manager one page each evening. It shows who got work done with the proof beside it, who is stuck, and who has gone quiet. When someone says a fix is finished and there is no merged pull request behind it, the report shows the claim and the missing evidence side by side, and leaves the judgement to you.
For a Jira team whose code is on GitHub, that already covers the case above: the ticket says QA, the check-in says done, and the report shows whether code actually merged. It does not replace Jira. Your team keeps planning, grooming and tracking where they do now.
To be clear about the limits: Eodly does not read Jira itself yet. Reading Jira column changes directly, so that "moved to UAT" can be checked against the code automatically, is on our roadmap. If your code is on Bitbucket or GitLab, Eodly can't check it today; the check-ins still work, marked as self-reported.
It is free for teams of up to 5 people, with no card needed, so you can try it on one squad for a sprint and see whether the bounces drop.
A simple way to start this week
- Write one line for what each column means and pin it in the team channel.
- Connect GitHub to Jira so every ticket shows its pull requests.
- For two weeks, count how many tickets come back from QA or UAT.
- Ask everyone for a three-line end of day: done, next, blocked, each with a link to the work.
If the bounce count falls, the board is getting more honest. If it doesn't, you have found the conversation worth having with your team, and you have the evidence to have it calmly.
Try Eodly free for up to 5 people.
Related reading