Skip to main content

How do scrum teams handle cutovers?

Last post 04:31 pm November 23, 2022 by Ian Mitchell
2 replies
03:48 pm November 23, 2022

So my product owner came to me asking how the team should manage cutover activities in scrum. I simply answered that the developers decide how they will execute the work since they have the skills and knowledge to build the product. After all they are a self-organizing and self-managing team. She did not seem too pleased with that response and said that it did not sound very agile? I then asked her why does she think that and she had no answer and tried to change the topic. I then asked her to elaborate on why she asked the question and she pulled up a cutover plan she created and wanted the team to use. I let her explain the cutover plan she created and asked her if she thought that giving the team a cutover plan that she created by herself with no input from the team was agile. She then said no and we started discussing another topic.

I just want to confirm if my response was sound? I've been a scrum master for awhile and I've never been asked any question about cutover activities before.


04:17 pm November 23, 2022

I'm not entirely sure what a "cutover plan" is but I am going to say that your response is heading in the right direction. The Developers decide how to turn Product Backlog Items into increments of value. However, the entire Scrum Team is responsible for achieving the Product Goal.  I am going to make an assumption that at "cutover plan" has something to do with the delivery of product updates because that seems somewhat logical to me.  In that case, I would expect that the entire Scrum Team would participate in defining those activities because it could involve work that is needed by the Product Owner and others outside of the Scrum Team.

This could be a good topic to bring up during a Sprint Retrospective. 


04:31 pm November 23, 2022

I'm afraid that when I've encountered the term "cutover plan" it has, unfortunately, been a euphemism for go-live.

In Scrum however, once work meets the Definition of Done, the imperative is to release it. There is no excuse for putting empirical process control in delay.

The team aren't forced into making a release, if it is no longer the right thing to do once the Sprint plan has been followed. In a complex and uncertain world, business conditions can change overnight. The thing is, the Product Owner would need an excellent reason to stop the release of Done work from happening. It's that way round.

In Scrum, we go into Sprint Planning every time with the genuine, serious, honest-to-God intention of releasing at least one Done Increment of immediately usable quality that Sprint. Hence the cutover plan is the Sprint plan, every time.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.