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


  • 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

6 Answers 6


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.

  • Thank you for your suggestion. I think me and developers will discuss and modify the DOD, and then I will leave the deploy in another sheets to keep track on. Thank you so much. Commented Oct 14, 2021 at 2:52

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

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.

  • My clients have their own strategy and they only let me know when they want to deploy this to production. I told them about the waste but they still want to pending all these users stories, for a week or a month even if they confirm that this feature work perfectly on staging. That's why I can't drag these user stories to the Done card. I don't know if they still want to this, so any suggestion for my board? Anw, I'm PO. Commented Oct 13, 2021 at 8:17

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.

  • 1
    Thank you for your suggestion, I will combine your suggest with Thomas Owens and Hans-Martin Mosner. Commented Oct 14, 2021 at 2:53

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

My suggestion would be to assign a name to each story based on the sprint it was worked on, and create a corresponding story for it. For instance, you can name a story "MessageHandler Deployment - Sprint 1" and link it to the feature to ensure you keep track of it. This will help avoid losing track of the story due to reasons like missing the deployment date or the customer not being ready to take it to production.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.