Why "18 of 20 done" doesn't always mean a release is ready

[Steve Gilliard]

Full disclosure: I'm with SG Development, the team behind Release Scheduler for Jira.

We kept running into the same conversation before every release: someone pulls up the fix-version board, sees 18 of 20 issues in Done, and calls the release "basically ready." Then release day arrives and it turns out one of those two open tickets was a P1 bug, another was blocked on a dependency nobody flagged, and a third ticket that looked done was actually still sitting in Backlog with a resolution someone forgot to clear. The board looked green. The release wasn't.

Percent-complete is a completion metric, not a risk metric. It doesn't know that one open bug is a blocker and another is a typo fix. It doesn't know two tickets are stuck behind an unresolved cross-team dependency. It doesn't know a ticket is still in QA vs. already through UAT vs. done. It just counts statuses.

That's the problem we've been chewing on in Release Scheduler: instead of one "% done" number, we compute a readiness score from several independent signals — actual completion, unresolved bug severity, blocking/blocked dependencies (including circular ones), schedule load vs. time remaining, and how far tickets have progressed through QA/UAT/Done rather than just whether any ticket reached Done. A release with three tickets stuck in Backlog scores differently than one where those same three are sailing through UAT — even though a naive "done/total" count would treat them the same.

It's still an imperfect model — we've had to go back and tighten it more than once as we found cases where it was too generous — but it's been a much more honest conversation starter with release owners than "are we green yet?"

Curious how other teams handle this: do you track anything beyond ticket status to judge release readiness (dependency risk, QA/UAT progression, schedule burn-down), or is "% done" still the main signal your team looks at?

Steve