Your sprint plan is only as good as its issue fields
A sprint plan looks like a decision about work. Underneath, it is arithmetic on issue fields: the estimates added up against the capacity, the due dates checked against the sprint's end, the links that say what has to happen first. The plan can only be as right as those fields.
And the fields drift. Nobody decides to leave an estimate empty or to put a due date after the sprint ends. It happens one issue at a time, in a busy week, and Jira accepts every one of them without a word.
Four ways a plan goes wrong without anyone noticing
- An issue with no estimate adds nothing to the sprint's total, so the sprint looks lighter than it is.
- A due date outside its sprint means the report says one thing and the board another.
- Two issues that block each other will never start. Each link was drawn honestly; nobody drew the loop.
- An issue marked done with work still on it makes progress look better than it is.
Why saved filters don't solve it
Each of these can be found with a Jira filter, if someone writes it, saves it and remembers to run it before every planning meeting. One filter per problem, a few dozen problems, every sprint. It does not happen, and the problems reach the plan.
What we built
Issue Checker for Jira runs thirty-four checks over a project's issue fields and puts every problem in one list, grouped: dependencies, something missing, dates and sprints that disagree, estimates, and work that looks finished but is not. Every check is shown whether or not it found anything, so an empty result is visibly a clean one. You can switch off the checks that do not fit your team, dismiss what you have decided to live with, and add checks of your own.
It cannot change anything in Jira. You fix what it finds, in Jira, and the plans, charts and reports built on those fields are right again.