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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


What is the best practice for managing related dependent issues in a Sprint

It is understood that it is not best practice to create stories which are not independently testable. Unfortunately, my team tends to create Stories which must be all be completed in order for code to deploy, and QA to commence.  Additionally, there is an expectation that when an item hits the "awaiting deployment to QA" column, that QA then request the deployment. However, because there are dependencies between stories, it is a challenge for QA to know, without a lot of manual steps, when all the pieces are ready?

We have discussed yet another column, or adding an additional link type, prerequisite or dependency, or similar. Then potentially we can automate the movement of the work item to the next status when all stories share the same defined status. What is the best way to manage this dilemma using Jira?

Thoughts? Best practices? Reading references?
Thank you!


1 answer

0 votes
Stephen Wright _Elabor8_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Mar 20, 2022 • edited

Hi @Misty Meyers 

I'd consider some things here...

  • E2E Flow: Look for where improvements in the flow can be made - for example, can Stories be written which can move to QA independently? 
  • Sprint DoD: Consider if the QA and/or deployment should be in the sprint - or if the last status in the sprint should be prior to this. For example, I've seen teams where completion of QA is "Sprint Done" - and the deployment to Production is only done every 2-4 weeks, and managed from the Release Hub, a Dashboard, etc, separate to sprints.
    • You can set "Sprint Done" by adding whatever status is deemed "Done" to the last column, with a green line in it. Remove the other, later statuses from the board.

^ I think I'd look at these two first, before looking at an automation rule, or more statuses, etc.

What do you think?


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events