How to deal with Ready To Deploy in Sprint Backlog
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
My initial reaction to this was that none of those things are yours. They belong to the team. You should change your view of all of this but that is not going to get you answer to your statement so I'll stop commenting on this topic for a moment.
To get a good answer to this question, you should be asking your Developers. They are closest to the technology and can provide you an answer that will work in your application. This will also provide the Developers an opportunity to participate in the modification of the Definition of Done that you created. The Definition of Done is a commitment made by the Scrum Team towards the increment. The entire Scrum Team defines and commits to it.
Nowhere in the Scrum Guide does it provide any guidance on the actually delivery of the work done. However since the Definition of Done states it has to be in Production, then your increments have to be in Production in order to be considered Done. What you don't state is that it has to be available to the users in Production. So I suggest that you use some type of feature flag so that you can deploy the code but hide it from the users until such time that they are ready for it. But that is just my suggestion based on what I have seen used before. Your Scrum Team should determine the best answer for your environment.
How can I deal with this?
- Ask the Developers to re-estimate the stories on the Product Backlog so they capture the outstanding work needed for deployment.
- Establish transparency over how the value invested in developing undeployed work is depreciating. It's a cost you are accountable for.
- Help the team to plan work in a more timely way so increments are genuinely Done and Sprint Goals are better met.
Many teams separate the concept of 'deployed' from 'released', by deploying a PBI to production toggled off. Once in production and toggled off, there are ways to validate the PBI without the customer seeing the PBI. When the customer is ready to accept the PBI, a toggle switch is turned on so that the PBI is officially released.