Yes, I've done this. It sounds simple, but it's actually rather tricky with Jira Automation. I'll try to summarize the approach that is working for us.
- - -
Rule A triggers on Create, Update, Transition and Move. It uses a Conditional right away to focus only on Story-level issues (so this rule ignores Epics and Subtasks). It then goes through a series of conditionals:
- If Story.Status != LowestStatus AND some Subtasks have Status=LowestStatus THEN transition Story to LowestStatus
- Same for NextLowestStatus
- Repeat through HighestStatus
So "todo" would be your LowestStatus and "done" would be your HighestStatus, with 2 in between. See the "important notes" below for exiting the rule after a conditional has fired successfully.
Note that Rule A will "force" the Status of a Story to be correct, based on the Subtasks. This prevents users from updating a Story to be inconsistent. It can seem odd on a Jira board, though to move a Story and then have Automation move it back. Boards that use swimlanes by Story work best here, helping users to focus on moving their Subtasks.
- - -
Rule B uses the same trigger as Rule A, but the initial Conditional focuses on Subtasks (so this rule ignores Stories and Epics). It also uses a series of conditionals:
- If Parent.Status != LowestStatus AND some sibling Subtasks have Status=LowestStatus THEN transition parent Story to LowestStatus
- Same for NextLowestStatus
- Repeat through HighestStatus
Again, see the "important notes" below for exiting the rule after a conditional has fired successfully.
- - -
A few additional important notes:
- I use a variable called ContinueFlag which is initially set to 1 (meaning the rule should continue executing). If a conditional matches, I set that variable to 0. Then after that conditional and the next one, I test the ContinueFlag in a Condition. The rule only continues if it is 1. That makes the rule terminate after the first matching conditional.
- I would recommend getting Rule B to work first, as it is easiest to test (perhaps in a separate project).
- Once you have both rules working, you will need to "bootstrap" each project (or if you're really brave, lots of projects). To do that, copy Rule A and change the Trigger to a Scheduled Trigger, use a Cron Expression of "0 0 0 1 1 ? 2000" (to keep it from executing), and check "Run a JQL search and execute actions for each issue in the query". For that JQL use "IssueType not in (Epic, Sub-task) and StatusCategory != Done". This focuses on only Stories which are not Done. You can use the "Run rule" button to bypass any schedule.
- This works well for Scrum teams/boards/project, but not so well for Kanban. This is because of how Jira handles the Backlog. Let me know if you want more details about the complexity that Kanban adds.
- Consider creating a set of manual "unit tests" that you can walk through and confirm proper operation. You'll likely make adjustments and enhancements to these (complex!) rules over time. And it always helps to be able to confirm that they are still working as expected. I documented those test steps and expected results in a Confluence page for my fellow Jira Admins.
- If your rules evolve to be more complex, you might find a need to use the "Re-fetch issue data" Action, or the "Sub-tasks present" Conditional, to ensure proper behavior.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.