The number that lied
Sprint 88 closed on a Sunday. The board read 100%. Every ticket moved to done, every story point burned. By any dashboard's definition, it was a clean week.
It wasn't.
Two of the "done" tickets were AI-assisted changes nobody had actually verified in production. One was a config change that worked fine on staging and nowhere else. The board didn't flag any of this, because the board isn't built to know it.
What 100% actually measures
A sprint tool tracks state transitions: open, in progress, done. It has no concept of whether "done" survived contact with reality. That's not a bug. That's the design. Jira, Linear, whatever you run, these tools measure motion, not verification. They answer "did the work move?", they never answer "did the work hold?"
That gap is where AI adoption breaks. AI makes it cheap to close tickets, but does not make it cheap to verify them. So the completion number climbs while the verification burden gets pushed downstream, usually onto whoever notices the outage on Monday.
The fix isn't a better dashboard
I didn't add a field to track "verified." I added a step to the retro itself: before any sprint counts as closed, someone states out loud what was actually confirmed working, not merely marked complete. It's slower, so it should be. Verification strain is a cost, and pretending it doesn't exist is how pilots die three months after the demo looked great.
A CFO doesn't care about story points. A CFO cares whether the thing shipped moved a number that matters, and whether someone can prove it. 100% on a sprint board proves neither.
The number I trust now
Sprint 89 will probably read 94%. That's fine. I'd rather run a system that tells me the truth slowly than one that lies to me instantly. The board was never wrong. I was, for trusting it to answer a question it was never designed to ask.