The board says the project is 80 percent done. The burndown chart slopes the right way. The status field says green.
Your team knows it is not. Two tickets have been "in progress" for nine days. One engineer is quietly blocked on a decision nobody has made. The integration that the whole thing depends on has not been started, because it is hiding inside a ticket marked done that was only ever half done. The project will not close on time, and everyone on the team knows it. The board does not.
This is the gap between what your tracker says and what is true. It is why status meetings exist: they are the manual patch over a tool that cannot tell you the truth on its own.
Why the board lies
Jira is not lying on purpose. It is reporting exactly what people told it. And that is the problem: a tracker only knows what a human typed into it, and humans update trackers late, optimistically, and inconsistently.
- Status is self-reported. A ticket is "done" when someone moves it, not when the work is actually finished. "Done" often means "done except for the part I will circle back to."
- Blockers are invisible. The most important fact about a project, what is stuck and why, usually lives in a Slack thread, not a Jira field.
- Percentage complete is fiction. Ten small tickets closed and one hard ticket untouched reads as "91 percent done." The hard ticket is the whole project.
The signals that actually tell the truth
Here is the thing: the honest signals already exist. They just are not in the status field. Real project health is sitting in the systems that record what actually happened, not what someone reported:
- How long things have been blocked. A task blocked for three days is a different risk than one blocked for three hours. The clock does not lie.
- The pull request and review queue. Work that is genuinely close to done has open PRs moving through review. Work that is not, does not.
- CI failure rate. A project whose pipeline is red half the time is not 80 percent done, whatever the board says.
- Where capacity actually went. Two engineers context-switching across four projects is a slipping deadline that no burndown chart will show you.
None of these require anyone to update a field. They are byproducts of the work itself, which is exactly why they are honest.
Health you do not have to maintain
The fix is not a better status field or a stricter rule about updating tickets. Those just add overhead to the same broken loop. The fix is to compute health from the signals the work already produces: how long things are blocked, what is moving through review, what CI is doing, where the team actually is.
When health comes from real signals instead of self-reported status, the number reflects what is happening, not what someone remembered to update three days ago. The status meeting stops being an investigation and starts being a decision.
Malvedeck computes project health from real signals, blocked time, review queues, CI, and capacity, so the number tracks reality instead of the optimistic version someone typed into the board.