How to deal with Ready To Deploy in Sprint Backlog

Question

I have a difficult question about how to deal with the ready to deploy user stories in the product backlog, as well as in the sprint backlog.

My current Kanban board is below:

To Do	In Progress	Testing	Ready To Deploy	Done
User Story 1	User Story 4	User Story 6	User Story 7
User Story 2	User Story 5		User Story 8
User Story 3

My DOD

• Pass all Acceptance Criteria
• Pass all Test Cases
• Deploy to Production
• PO confirmation (Who is me)

My current problem is that my clients does not want to Deploy to Production, so that I can't move User Story 7 and User Story 8 to Done.

How can I deal with this?

My solution is that put all Ready To Deploy stories back to Product Backlog and create another user story called "Waiting to Deploy" and linked all Ready To Deploy stories to this story.

If I can't, so how can I deal with this?

Thank you Thank you

Best Regards

Answer 1

I'm going to take it a step further than Hans-Martin Mosner did in his answer. Things that are outside the control of the team should not be part of the Definition of Done nor should they be on the team's board. Since the team cannot choose if and when to deploy work that meets the other criteria to production, the team should consider the work Done with a signal to the other stakeholders that it is fit for deployment.

If you want visibility, I'd consider a more abstract, higher-level Kanban board that has columns such as "Backlog", "In Development" (which represents the To Do, In Progress, and Testing columns on the development board), "Ready for Deployment", and "Deployed". On this higher level board, once card has progressed through testing, it "falls off" of the developer's board (since it's done) and moves into the Ready for Deployment state on the more abstract board. This keeps the team board nice and clean, and also lets you and the stakeholders have visibility into what can be deployed.

Answer 2

My naive point of view would be that since it's not your decision to deploy or not, those stories should not be in your Kanban board but in your client's board (if they have one, or in their mailbox, or on their desk). You've finished your work (presumably, with tests asserting that the client's requirements are met) and now your work is done. If you're a DevOp shop and also responsible for deployment when the client decides to deploy, deployment activities should enter your Kanban board as separate cards (which is somewhat comparable to your current approach of putting the Ready To Deploy stories back to Product Backlog but makes it explicit that Deployment is a new story, not an unsuccessfully implemented story that needs to be restarted.)

Realistically, you seem to have a process problem and should talk to the PO and client about this. If they are blocking the deployment process, they are creating waste. You probably need to find out what causes the client to not want to deploy. Are they overworked and don't have time to do their part? Do they assume that stories that you marked as ready for deployment aren't really production-ready?

Shuffling stories around and creating more administrative overhead will not solve the underlying problem.

Edit: After some browsing, it seems that some would keep blocked tasks on the board, with some indication that they aren't waiting for your team to get around to them but blocked by external factors. This is mostly useful if elimination of the blocking factors is at least partly under your control and could be subject to process improvement (for example, if a task is blocked because requirements are unclear, you could work on getting better requirements for this task to unblock it, and find ways to get more complete requirements in future to avoid similar blockers). In your case, the blocking does not seem to be under your control, so I'm not sure whether this point of view is helpful.

Answer 3

Since the deployment is a time-based action;

1. Someone has to spend time on it, so it must be estimated
2. Someone has to do it at a time, so it must be something considered as a work in a sprint

Here's what I suggest;

1. Remove "Deploy to production" from your DOD
2. Create separate stories for the releases and relate the completed stories to that release story

Answer 4

The stories have not met the definition of done and so should be left in the ready to deploy state.

The idea behind the concept of 'done' is that it is how the team defines the end of their work on a particular story. If it is yet to be deployed, then there is work still to be completed and potentially there may also need to be re-work if there are problems during the release.

If you are worried about the accumulation of stories in 'ready to deploy' then I would suggest reviewing your definition of done. However, I would caution that this approach may result in a false sense of progress. For example, stating that 10 stories are 'done' when in fact there is still work to be completed and you can't quantify the effort that may still remain.

Answer 5

Deployment may have dependencies. In many cases, some of the stories/tasks may not be able to be deployed until a specified time. I second this approach

• Remove "Deploy to production" from your DOD
• Create separate stories for the releases and relate the completed stories to that release story