Deployment of issues not being deployed after each sprint

[Shari Fitz-Patrick]

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.  

[Jack Brickey]

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.

[Shari Fitz-Patrick]

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]

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 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]

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]

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?