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,460,039
Community Members
 
Community Events
176
Community Groups

Deployment of issues not being deployed after each sprint

We do not deploy code after each sprint so therefore Issues in the 'Ready for Deployment' column could sit there for a number of sprints.  I was going to change the definition of DONE to Product Owner Review.  That leaves me with two columns Approved for Deployment and On Pre-Production.  What would you recommend we do with these issues as they could sit around for a number of weeks.  

1 answer

0 votes
Jack Brickey Community Leader Jun 16, 2022

Here is my suggestion it may or may not work for you but it has for me in the past. You will have two boards a scrum board for the development that would end with ready for deployment right most column. The second kanban board would be used for deployment it would begin with ready for deployment and end with done in the right most column. And this way your development scrum board will be nice and clean and the kanban board provides the flexibility of deploying code as appropriate.

Thank you.  I actually tried that out before receiving your answer.  I am pleased to see that you recommend the same thing. I do have one more question.  Is there a way that the issues that are in the first board with the status ready for deployment could then be automatically moved to the second board with the status of ready for deployment?

Jack Brickey Community Leader Jun 20, 2022

Yes. In fact that is how I would recommend it. Basically, you would have that status as the last column in your dev and the first of your deployment board.in this way there is a desirable overlap.

Yi Wang I'm New Here Nov 11, 2022

I have the same challenge and want to adopt the same. I have a few questions

#1 do I need to create two projects? One development project and the other is deployment project. There will be one board for each project.

#2 how do I connect the two boards under two different projects?

Jack Brickey Community Leader Nov 11, 2022
  1. no, and in fact this discussion is about a single project. Your requirements may dictate 2 projects. With two projects the solution gets more complex as you have to move the issue from the dev to the deployment project. Or you can close out the dev issue and ope another issue in the deployment project and link the two. This could all be done with Automation.
  2. you don't connect the boards. What would you be attempting to do by "connecting" them? If you have one project you could have both boards in the sidebar. If two projects then I would add a link in both project sidebars to the other project's board for ease of access.
Yi Wang I'm New Here Nov 16, 2022

Thank you Jack.

 

I did not know you can create more boards for a project. I do need to explore the multiple board approach, but I think another approach might work better for us. I think even with multiple boards, it won't solve the problem that completed dev items won't be ready to deploy until multiple sprints later. And I need to close the dev sprints to keep my board current and clean. I acknowledge I may not fully understand the proposed solution.

We are thinking of keeping a static sprint called Test Sprint, which will contain shell user stories that links the user stories in each of the development sprint. The development sprint is always the current sprint and last two weeks, the Test Sprint is where I managed the testing. Do you see any issues with this approach?

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events