Parent issue follows latecomer child

[Stéfano Matos]

Hi everyone, I have an issue regarding automation on Jira ruining my sleep. 

If you are working with a Kanban board that has all issuetypes filled in, you must have noticed that It is very inconvenient to move parent issues through the board as their children move every time, specially if you have many children attached.

So, I came up with a logic to encounter such impasse and decided to carry out an automation experiment. Since then, I've been facing technical issues on Jira's Automation tool and I hope you guys have already overcome them.

Being so:

As we know, conceptually all sub-tasks must be done for a User Story (US) or any other standard issue to be considered done as well, therefore, an US should follow its children sub-tasks, particularly its latecomer, throughout the board's workflow to be in the accurate spot on the flow.

Which means that if an US has 2 or more linked Sub-tasks, the same US is supposed to sit idle on the same column as the last latecomer child Sub-task. In other words, if 1 User Story has 3 linked Sub-tasks spreadout across 5 board columns, the User Story must follow the particular child Sub-task that fell behind at the first column of the flow. 

Is there anyone who came across such problem before? How would you guys approach it?

[Stephen Wright _Elabor8_ · Accepted solution]

Hi @Stéfano Matos 

Can you clarify...

• What automation rules are setup for Stories / Sub-tasks
• What Workflow post-functions are there in relation to Stories / Sub-tasks
• What behaviour you would like to happen - is it...
  • A User Story should be separate from it's Sub-tasks' transitions or...
  • A User Story should automatically change Status depending on where each of its Sub-tasks are up to

Natively, the Story and the Sub-task do not depend on each other for Status moves - if this is happening automatically now, then there is already some customisation implemented.

It'd also be good to understand what technical issues you now have from automation.

Ste

[Stéfano Augusto de Matos]

Hi @Stephen Wright _Elabor8_ , thanks for replying my issue.

There is no automation rules set up nor workflow post functions. In fact, that's what I'm looking for.

My team and I agreed that all Sub-tasks must be done in order for their related User Story to be considered done. Note that both Issuetypes are set to move though our Jira board.

I know that they move independently, but I would like to set up an automation rule to force an User Story to follow its related Sub-tasks statuses. However, one User Story might have several related Sub-tasks, so which Sub-task's status it should follow then?

A Jira board represents a flow, so statuses are configured on the board one before the other in a row, right?

My idea is to set a User Story to always follow the latecomer Sub-task status on the board. That ensures the User Story won't be set as done in case one of the many related Sub-tasks is moved to the end of the board (status done) as the others sit idle on any other board column.

Hope I've provided enough information this time. 😅 Sorry for not being clear before.

[Stephen Wright _Elabor8_]

Hi @Stéfano Matos 

This should be possible - I've provided an example of how it could be done below based on the latecomer approach.

A few general notes on my approach:

• You'd need to test this with your Workflow. My Workflow was open (all <> all transitions).
• The parent and sub-task Workflows matched for me.
• This is an example rule - it might not be exactly what you need (for example, different conditions might be needed). You'll need to do some testing.

Some further explanation is below the example.

---

• Trigger: Issue Transitioned
• Branch: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "To Do"
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: To Do
  • Action: Transition Issue - To Do
• Branch: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "In Progress"
  • Condition: Related Issues Condition
    
    • Related Issues: Sub-tasks
    • Condition: None match specified JQL
    • JQL: status = "To Do"
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Progress
  • Action: Transition Issue - In Progress
• Branch: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "In Review"
  • Condition: Related Issues Condition
    
    • Related Issues: Sub-tasks
    • Condition: None match specified JQL
    • JQL: status in ("To Do", "In Progress")
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Review
  • Action: Transition Issue - In Review
• Branch: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: All match specified JQL
    • JQL: status = Done
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: Done
  • Action: Transition Issue - Done

---

Some design notes...

• Each Branch is effectively an if/else rule. The branches allow for a sub-task to be the trigger, whilst also checking the parent, and all sibling sub-tasks.
• The branches work as follows...
  • Middle Branches... 
    • Looks for some issues being in that specific status
    • Checks that no issues are in the previous statuses
    • Checks that the parent isn't already in the target status - this is important for all <> all transitions, to stop same-status transitioning
  • First Branch...
    • Only checks some issues are in that specific status - as there's no previous status to check
  • Last Branch...
    • Only checks all issues are in the "Done" status - as all sub-tasks need to be complete to close the parent
• The reason I've used some/no issues - rather than all issues - in the related condition, is that this ensures the parent can move forwards, or backwards, following the sub-tasks. This might not be an issue in a closed workflow though, and the condition All match specified JQL might suffice.
• You might need to set more fields in the "Done" status - such as resolution, etc

---

Let us know if this works for you, or if you have any further questions!

Ste

[Stéfano Matos]

Hi @Stephen Wright _Elabor8_ . I'm very thankful for your assistance. Your suggestion seemed to address my problem perfectly. I just tried it out but I happened not to have success as expected. I'm going to explain why in as much details as I can. BTW, my workflow is pretty much the same as yours (All <> all transitions).

For the sake of explaining it, let's call a User Story as Parent and Sub-tasks as Children.

Also, let's say there is 1 parent for 4 related children.

1 child is "To Do", 2 children are "In Progress", 1 children is "In Review".

Given that "To Do" is where the latecomer child is, the Parent was supposed to be there as well, right? 

Moreover, when I move the 1 lonely "To Do" child to "In Progress", along with the other 2 children, the Parent should follow it and turn its status to "In Progress" as well.

Now there is nobody "To Do" and those 3 "In Progress" children are the latecomers, given that there is another child ahead "In Review".

In summary, the Parent was supposed to follow the children's status closest to the set beginning of the flow.

Appreciate your help.

Stéfano

[Stefan Salzl]

One question for my understanding (as the logic doesn´t make sense as I get it):

To stick to your example: Let´s say there is even 2 children "Done", 1 "In progress" and 1 "To do". As I got you right in this case the parent should still be in status "To do" as there is 1 child (latecomer) in this status.

My question is:
Does your parent status then really shows the truth/transperency? How could the story be "To do" if there is a child "in progress" and EVEN 2 children "Done"?

Best
Stefan

[Stéfano Augusto de Matos]

Hi @Stefan Salzl , thanks for replying my post. 

Your question makes total sense.

The parent should be "In Progress" whenever the first child goes. However, it should not keep moving ahead even though other children are already done. As long as there is a child in progress the parent should follow the latecomer one.

I planned on adding a condition to work that out later. First, I'd like to figure out the "parent follows latecomer child status" automation rule

[Stephen Wright _Elabor8_]

Hi @Stéfano Augusto de Matos

Alright, so I think I've worked out the intricacies of this rule, mapped to the latter comments about moving to In Progress when the first child moves.

I've gone for ease of understanding over efficiency, so this might be possible to refine slightly - but the rule has 6 branches...

Branch 1:

• If all sub-tasks = To Do
• And Story != To Do
• Transition Story to To Do

Branch 2:

• If some Sub-tasks = In Progress
• And Story != In Progress
• Transition Story to In Progress

Branch 3:

• If some Sub-tasks = To Do
• And some Sub-tasks = Done
• And Story != In Progress
• Transition Story to In Progress

Branch 4:

• If some Sub-tasks = To Do
• And some Sub-tasks = In Review
• And Story != In Progress
• Transition Story to In Progress

Branch 5:

• If some Sub-tasks = In Review
• And No Sub-tasks = To Do, In Progress
• And Story != In Review
• Transition Story to In Review

Branch 6:

• If all Sub-tasks = Done
• And Story != Done
• Transition Story to Done

---

^ I think this covers every need, ensuring...

• If all in To Do, or all in Done - those statuses are set for Story
• If any Sub-task is in In Progress, Story matches
• If all Sub-tasks are in In Review or later, Story matches
• If Sub-tasks are in To Do, In Review, and/or Done, Story is In Progress

For the last two bullets, it effectively means a Story can be In Progress when no Sub-tasks are, so it's not ahead of the Sub-tasks in To Do!

---

So, how does this rule look?

• Trigger: Issue transition
• Branch 1: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: All match specified JQL
    • JQL: status = "To Do"
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: To Do
  • Action: Transition issue - To Do
• Branch 2: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "In Progress"
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Progress
  • Action: Transition issue - In Progress
• Branch 3: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "To Do"
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = Done
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Progress
  • Action: Transition issue - In Progress
• Branch 4: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "To Do"
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "In Review"
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Progress
  • Action: Transition issue - In Progress
• Branch 5: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: Some match specified JQL
    • JQL: status = "In Review"
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: None match specified JQL
    • JQL: status in ("To Do", "In Progress")
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: In Review
  • Action: Transition issue - In Review
• Branch 6: For Parent
  • Condition: Related Issues Condition
    • Related Issues: Sub-tasks
    • Condition: All match specified JQL
    • JQL: status = Done
  • Condition: Issue Fields Condition
    • Field: Status
    • Condition: does not equal
    • Value: Done
  • Action: Transition issue - Done

---

There's some reasoning to the design, but in summary it appears to work in all the scenarios I could think of for my Workflow example.

You'll need to expand/constrict the rules depending on the number of Statuses you have between To Do and Done.

Give this a go - let us know if it works, and feel free to ask further questions if needed :)

Ste

[Stéfano Matos]

Hello @Stefan 

I'm happy to say that your suggestion worked pretty well. 

Thank you and @Stephen Wright _Elabor8_ very much for taking the time to help me out with it.

Best regards,

Stéfano

[Stefan Salzl]

Hi @Stéfano Matos and welcome to the community.

first:

 to move parent issues through the board as their children move every time

I cannot confirm this behaviour as default in kanban boards. I didn´t see all sub-tasks changing with transition of a UserStory. If this happens I suppose there is already an automation rule or post-function processing this.

The other thing is more a question of the design of your process hence workflow(s). You could also have different workflows for special issue types (means: subtasks could have a different workflow than user stories). To really understand your case it would be helpful to add a screenshot of your board and describe your use case based on an exact expample (referring to your board).

Best
Stefan