Issue Health-checks
Just as a recap, this feature is designed to help teams identify issues that are at risk of either delay or quality defects by checking the issue content and history against some common rules. A ‘risk level’ is then determined for that issue based on the number of ‘failed’ rules. Issues are re-evaluated whenever they are edited or viewed while In Progress.
You can choose which rules you would like to apply to your issues and how many failed rules determine each risk level. It won’t make sense for most teams to enable all rules as some are more geared towards Scrum or Kanban.
Jump to a rule
The following goes into detail for what each of the rules are, how they might be useful for your team to apply, and ways to improve on these if they occur frequently.
- Due Date is set and Current
- Number of Due date changes
- Number of Sprint Changes
- Times in an In Progress status
- Duration in Progress
- Issue Assignee
Due Date is set and current
The Due Date issue field in Jira is important for setting expectations about when a particular piece of work will be delivered. This rule checks that an issue:
- Has a Due date set
- Has a Due date that is set in the future.
An issue without a due date is like a blank cheque; there’s no firm commitment to when it will be delivered. An issue with a due date in the past has slipped and should be re-forecasted to help reset expectations.
How to improve this
- Encourage team members before standups to check their issues and see if the due date requires adjustment
- Set up a quick filter with a JQL like
statusCategory = "In Progress" AND (duedate IS EMPTY OR duedate < endOfDay())to display these issues - Use color coding on Jira boards to highlight issues without due date in Dark Red and Overdue issues in Red
Number of Due date changes
This rule checks for the number of times the due date has been changed while an issue is In Progress. If it has been changed more than twice, this rule fails. Currrently, this rule does not distinguish between changes to earlier dates.
The Due Date changing multiple times might be a symptom of the issue being more complex than originally intended or more scope being added on. This rule is designed to act as a trigger for discussion to revist scope and / or complexity.
How to improve this
- Ensure that issues have a clear scope before moving into In Progress
- Aim to create smaller, self-contained issues that tackle more specific elements of scope
- Review issues that fail this rule to identify any commonalities between them
Number of Sprint Changes
This is the Scrum variant of the Due Date change rule. If an issue moves between sprints once it is In Progress, it could be symptomatic of the scope or complexity being greater than anticipate.
How to improve this
- Ensure that issues have a clear scope before moving into In Progress
- Aim to create smaller, self-contained issues that tackle more specific elements of scope
- Review issues that fail this rule to identify any commonalities between them
Times in an In Progress status
This rule assesses how many times an issue has been in and out of an In Progress status. This can be symptomatic of the issue being de-prioritised in favour of other work or that it’s scope / complexity was more than the assignee had time available to be able to close.
Issues like this can be risky if they are not particularly important to complete, but distracts members of your team who contribute to planning discussions or who actually pick this up.
How to improve this
- Be decisive about the stated priority of issues
- Ensure that issues have a clear scope
- Review issues that fail this rule often and be decisive about whether they should be closed.
Duration in an In Progress status
This rule checks how long an issue has spent in an In Progress status and compares this to the recommended duration for each Jira Issue type. As a general rule, these are set to:
- Epics - 6 weeks
- Stories, Tasks, other issue types - 7 days
- Subtasks - 2 days
This rule is designed to help teams right-size the scope of their tickets based on the issue type, and act as a heuristic for discussing the scope when it starts to run over.
How to improve this
- Document how your team should use different issue types.
- Review scope and choice of issue type during backlog refinement
Issue Assignee
This rule checks that an issue that is In progress has an Assignee set. Many teams “walk the board” by user which means that issues that are being worked on without an assignee can sometimes be missed. It also means that if these issues start to go off the rails, it is unclear who to reach out to discuss them.
An issue that is being worked on should always have a primary owner.
How to improve this
- Add a Jira Automation that sets the Assignee when the issue is put into progress, if not set
- Add a quick-filter that shows unassigned issues that are in progress:
statusCategory = "In Progress" AND assignee IS EMPTY - Use the above quick filter as part of your stand-up / planning rituals
More rules?
We are planning to add new rules and the ability to further customise how these rules work for your team.
Got some ideas for some improvements? Please feel free to contact us to let us know!
