Skip to main content

What if the servers break down?

Last post 02:28 am September 30, 2015 by Niels Dimmers
7 replies
05:09 am September 29, 2015


It is a very practical question. Let's say we are operating a shop online. We are adding step by step, sprint by sprint, new functionality. And, suddenly server break down. Should the sprint stop? I guess yes, but who is taking the decision?

How would it be managed?



10:19 am September 29, 2015

In my opinion is a bad idea that the development team that is adding new functionality to the product is also responsible of maintaining the product in Production environment. Working this way the team will be continuosly affected on his sprint goal for events outside the Sprint. This is something that the SM should manage with the Managment.


Julio Mieza del Val

11:13 am September 29, 2015

IMO, dev teams should also support their systems in production. They should "eat their own dog food." Said another way, by having dev teams support production, the dev teams get maximum transparency on the decisions they make, esp wrt quality and customer satisfaction.


See here for one way to handle production support issues that you describe:

11:43 am September 29, 2015

You are right and maybe they should eat that food, but I think this is againts the SCRUM framework, because none of the tasks needed for put the server up (incluiding hot fixes) are in the Sprint Goal, and the dev team has to work only on the tasks of the Spring Goal in the whole Sprint.

Making the team working on task outside the Sprint Goal is a wrong approach for releasing SCRUM in a company, it would affect the sprints for sure.


12:58 pm September 29, 2015

Responding to emergency Production Support issues could be a part of the Sprint Goal, yes?

The Sprint Goal can be just about anything a Scrum Team thinks is valuable.

04:25 pm September 29, 2015

As far as I know The Sprint Goal is an objetive set for the Sprint related with the implementation of 1 or more items of the Product BackLog. If we add in the Sprint Goal this kind of unpredictable, unknow and unestimated tasks its going to be very difficult for the team the commitment necesary for finishing the tasks that really are adding value to the product.


01:22 am September 30, 2015

If the server breaks down, would the Development Team still be able to deliver a potentially releasable increment?

If not, then the problem should be regarded as an impediment to the Sprint Goal and handled accordingly. The Scrum Master should take a lead on resolving the matter, and the Development Team should self-organize to find workarounds. This may involve finding alternative release environments and/or renegotiating the Sprint Backlog with the Product Owner so the Goal can still be met.

If the server hosts the Product, then the PO would also have an interest in resolving this matter, such as by resourcing alternative hosting infrastructure.

02:28 am September 30, 2015

In the team I work in, this is a constant issue. We are both responsible for delivering new functionality using the Scrum framework, and the (technical) support for keeping the production environment of our system up and running, including 24/7 (standby) support.

My employer says it is "DevOps" and I (the scum master) call it a pain in the *ss, but it is something we have to deal with. After a few sprints we know how much time we require for keeping the system up and running and take this into account when planning the sprint. If there are a lot of incidents I discuss the issue with PO and together we decide which stories can be dropped from the sprint.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.