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,467,298
Community Members
 
Community Events
177
Community Groups

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

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?

Ste

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events