Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,365
Community Members
 
Community Events
176
Community Groups

Parent issue follows latecomer child

Edited

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?

2 answers

1 accepted

1 vote
Answer accepted

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

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.

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

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 Community Leader Mar 20, 2022

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

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

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

Like Stéfano Matos likes this

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

Like # people like this
0 votes
Stefan Salzl Community Leader Mar 18, 2022

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events