Automation Rule - Move a linked QA story to current Sprint when the DEV story is moved to done

[Derek Zhou]

Context:

Have a Dev and QA stories created separately and is linked using relationship "tests". I'd like to create an automation rule for the following:

Given: Dev story is in the current sprint

When: move the Dev status to done from "in progress" or from "to do"

Then: auto move the linked QA story from the backlog to the same sprint as the Dev story, and send a notification to the assignee of the QA story

Thank you in advance!

[Deivid Araujo]

Hi Derek. Welcome to the Atlassian Community!

See if this approach can help you:

• Trigger

  • Use Issue transitioned → “To status = Done”.

  • Add conditions: “From status = To Do OR In Progress”.

• Condition (Sprint check)

  • Add Issue fields condition → Sprint = “is not empty”
    (this ensures the Dev story is in an active sprint).

• Branch Rule: Linked Issues

  • Branch: “For linked issues” → link type = tests.

  • Now inside this branch, you’ll operate on the QA story.

• Action: Edit issue

  • Edit Sprint field → set it equal to {{triggerIssue.sprint}}
    (this copies the sprint from the Dev story to the QA story).

  • If the QA story is in the backlog, this moves it into the same active sprint.

• Action: Send notification

  • Action: “Send email” or “Send Slack/MS Teams message” or “Comment on issue”.

  • Send to: Assignee.

  • Example: “Your QA story {{issue.key}} has been pulled into the sprint because {{triggerIssue.key}} is Done.”

[Amanda Culver]

This is automating a process that should be a conscious decision.

I would have a conversation with the requestor as this is breaking sprint management. 

Sprint management :

• What is my team composed of ?
  • 3 x developers
  • 1 x architect
  • 2 x QA
• How many Story Points fit within /this/ team's sprint ?
  • is the span of the total story points correctly spread across my resource types ?
• What are my priorities / dependencies / commitments / etc ?
  
  • feeds into which Epics / Stories / QA / etc will be allocated for the sprint
• etc

If the QA resource sits within the sprinting team, then their work items should have been included in the scope of the sprint.

CAUTION : 

If the QA team are separately sprinting, they may have scheduled the work item for a future sprint.

This smells like pulling the rug from under scrum master's feet ... there may be trouble ahead.