One of the recurring Scrum Myth discussions I have with colleagues, teams new to Scrum and those attending training when comparing Scrum & DevOps relate to a misinterpretation of the following paragraph from the Scrum Guide.
At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
Scrum Guide
The discussions tend to start from the basis that Scrum prevents a Scrum Team from releasing more regularly than at the end of the Sprint and is therefore slower than DevOps at getting releases into the market and users hands for feedback.
I generally suggest they re read the statement and look to see if they can find any part or sentence in it that explicitly says that a Scrum Team may only release at the end of the Sprint. I see this as being the minimum state in the ‘What’ that the Scrum Framework describes the Increment must be in at the end of the Sprint. Like any other minimum if you can get to that point earlier then you should if possible take advantage of the early delivery.
When people come either to community discussions or training on more advanced use of Scrum they realise that the same techniques of Continuous Integration, Continuous Delivery, Continuous Deployment are all recommended Complimentary practices in Scrum implementations in order to be successful. A follow up question relates to where the increment should be deployed to by the end of the Sprint. This can be defined in a Scrum Teams Definition of Done taking account of at what point on the particular platform are all tests run that mean the increment is in a potentially usable / releasable state.
I personally work with many teams that deploy fully tested and integrated code to live multiple times within a day using Scrum to deliver robust, scalable Enterprise Applications with millions of users per month.
So “Using Scrum can you have multiple releases in a Sprint”. Sure you can you just need to think how Scrum enables you to achieve delivery instead of what a process stops you from doing.
Scrum Myth: You can only Release the Product at the end of the Sprint
What did you think about this post?
Share with your network
Comments (3)
In a similar argument, I often hear the software MUST be in the production environment by the end of the sprint. This takes the decision to "release" out of the Product Owners hands and unjustifiably places it into the definition of done and therefore the dev team. The product owner should have every opportunity to slow deploys to a production environment.
The dev team need only maintain the deployability of the entire solution. And to that respect, may need to tell the product owner that they should go to production soon as not to make a huge deploy when changed may encounter unforseen issues.
Absolutely!
Yes I would agree the DoD should not take decisions that are the domain of the Product Owner and it is the Product Owners decision when to release. In your particular situation I would have advised them that the DoD may state that it should be in a state ready to deploy to live but the decision to go live should remain with the PO.