You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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?
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?
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?