A synchronized, distributed workflow for EPIC and related User Stories may look like the following sample:
Image Added
Usage
Extend workflows 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:
Image Modified
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!
Image Modified
Nevertheless, it's category is "Done" as well with respect on related agile board configurations.
Image Modified
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.
Image Modified
Image Modified
Generally: detect workflow transition ID to be triggered for status changes of target issue(s) and add post function for source issue to synchronize
Image Modified
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:
Image Modified
Add a post function for synchronizing:
Image Modified
Image Modified
EPIC
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.
Image Modified
The configuration is displayed as short summary:
Image Modified
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
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.
Image Modified
Image Modified
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.
Image Modified
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.
Image Modified
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".
Image Modified
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.
Image Modified
Linked issues
Trigger status change of linked issues (outwards) - top down
Please see "Parent Issue" above but select a different "Link Type".
Image Modified
Trigger status change of linked issues (inwards) - bottom up
Please see "Subtasks" above but select a different "Link Type".