Introduction to synchronized but distributed workflows

In a lot of different business scenarios, you end up having hierarchies of issues like EPIC and related user stories using JIRA Software or issue hierarchies represented by issue links like within JIRA Portfolio or just subtasks of issues within JIRA Core. Generally, this issues are of different issue types having their own workflows and statuses. Issues on higher hierarchy levels are more general wheres as issues on lower hierarchy levels are more fine-granular. Nevertheless there are points in time, sometimes named "quality gates", when status of different issue levels should be synchronized. You can do this manually, but it is failure-prone and not effective. Just imagine the following scenarios:

• Scenario A: automatically, set status of EPIC to "in progress" if first user story is started
• Scenario B: automatically, set status of EPIC to "is developed" if all user stories are ready for testing. Next step of the EPIC may be "start integration test" triggering workflow transition "start test" of the related test-task switching into status "testing".
• Scenario C: automatically, set status of all user stories to "cancelled" if related EPIC is switched into status "cancelled" in order not to spent more time and budget into this stories
• Many other scenarios are possible to automatically trigger a status change of one or all issues on a different hierarchy level: top-down or bottom-up.

Purpose

Getting high business value by automating transitions in complex scenarios to reduce manual efforts and failures and to react in real-time using distributed but synchronized workflows.

Configure workflow post functions

Extend your workflow(s) via JIRA's standard approach

Please switch into JIRA administration, select tab "Issues" and choose "Workflows" on the left menu getting a list of all available/configured workflows. Select the workflow you want to extend/modify and click on "edit" as shown below:

Depending on your existing workflow steps, you want to just add a new post function to synchronize statuses or to add an additional step. The simplified workflow provided within JIRA Software for EPICs and user stories is too focussed for the examples. So, let's extend it a bit by allowing product owners to cancel an issues in addition if business has changed (this is something different from being "done") and automatically synchronize the EPIC if all user stories are ready for testing!

Nevertheless, it's category is "Done" as well with respect on related agile board configurations.

Now, add a new status for example "Pending" using the same approach and create a workflow transition from "In Progress" e.g. named "ready for test" (transition ID #71, here) to it. Then add another status "In Test" having a transition "start test" (transition ID #51, here) from status "Pending" and a transition "stop test" (transition ID #61, here) into status "In Progress" if tests fail.

Generally: detect workflow transition ID to be triggered for status changes of target issue(s) and add post function for source issue to synchronize

Select your workflow to be modified, click on the workflow transition of the issue type (here: EPIC) which should trigger status changes of related issues and switch to its configured post functions:

Add a post function for synchronizing:

EPIC

Trigger status changes of all related User Stories

Business Case, here: canceling an EPIC by the procuct owner automatically transitions all related user stories into status "canceled" to avoid continuous efforts and budget on them.

Select Link Type "EPIC link" and Link Direction "outgoing links" to specify all issues referencing current issue within their custom field "Epic Link" as target issues.

Do not click on "Homogenious Status" (no restriction of sibling issues' statuses: all issues linked to the EPIC shall be triggered regardless of their own status) and select Sync. Status "any" (no restriction of target issues own status).

Finally, specify the transition ID, which will be triggered on all target issues if the EPIC will be changed it's status, and click on the "Add" button on the bottom of the page.

The configuration is displayed as short summary:

Now, click on "publish draft" so that your configuration becomes active. Finally, test your configuration by selecting an EPIC of your choice, click on "canceled" and have a look at its related user stories: all of them should be canceled as well. If not, please continue to detect your problem as described.

User stories

Trigger status change of related EPIC if all user stories are "ready for testing"

Select Link Type "EPIC link" and Link Direction "incoming links" to specify the referenced EPIC of current issue/user story as target issue.

Click on "Homogenious Status": the last user story of all sibling issues of that EPIC shall trigger the status change of their EPIC and the EPIC's (Sync.) Status is "any", here. If the transition cannot be executed because the EPIC's status does not allow that transition, it won't be done.

Finally, specify the transition ID, triggering the target issues/EPIC and click on the "Add" button on the bottom of the page.

It is important to move down the new workflow post function as indicated in blue in order to work properly: if the workflow post function is executed before setting the issue's status, it has got a different status than the other sibling issues although it may is the last one, then the related transition will never be executed based on configured dependency.

Parent issue

Trigger status change of all its subtasks

Within the following sample, a new post function for transition ID #31 ("done") will trigger the same transition ID #31 for it's related parent issue by the last of all sibling subtasks.

Business Case, here: canceling a parent issue automatically transitions all related subtasks into status "canceled" to avoid continuous efforts and budget on them.

Subtasks

Trigger status change of parent issue by the last subtask being "done"

Within the following sample, a new post function for transition ID #31 ("done") will trigger the same transition ID #31 for it's related parent issue by the last of all sibling subtasks.

Business Case, here: the last of n subtasks transitioning into "done" switches the parent issue into status "done".

Trigger status change of parent issue by first-coming subtask status change

Within the following sample, transition ID #21 ("in progress") of a subtask triggers the same transition ID #21 but it's related parent issue if it is still within status "to do" otherwise no transition will be done.

Business Case, here: the first of n subtasks switches the parent issue into another status.

Linked issues

Trigger status change of linked issues (outwards) - top down

Please see "Parent Issue" above but select a different "Link Type".

Trigger status change of linked issues (inwards) - bottom up

Please see "Subtasks" above but select a different "Link Type".

Related pages