Skip to main content

Hotfix in the middle of sprint

Last post 09:44 pm December 3, 2021 by Tania Zhydkova
13 replies
10:14 am January 15, 2013

Hi guys,

What if there is a severe defect in the system that needs to be fixed in the middle of the sprint?

I mean, there is no way that I can say "no, I'm not adding this item to sprint backlog". And I can't wait the end of the sprint to deploy it.

1- Should I terminate the sprint?

2- There are 10 people in the team and only one of them will deal with the bug. The other 9 should continue their sprint tasks even if I terminate the sprint?

3- I think I know the answer but, when we fix the bug, I shouldn't deploy other items from sprint backlog, right?

Thanks a lot


01:36 pm January 15, 2013


I would not terminate the sprint in this situation. Terminating a sprint is a very rare occurrence, and only when the vast majority of the sprint work is of zero value going forward. For instance, if a company gets bought out by another company, or the company does a re-org, etc -- but again... only if the value of the vast majority of the sprint work is no longer of any value whatsoever.

Understanding that I cannot see your full context from far away, and that I'm only going on what you told me, I would just have the person fix the bug ASAP. In terms of deploying the other functionality -- that's an organizational decision. My experience is that it's not usually a good idea to deploy new functionality with a severe fix, as it could cause confusion and possibly introduce more bugs/risk than is necessary.

As for how to account for this situation from a Scrum perspective, here is one way to deal with a hot fix and other bug/production issues:

04:48 pm January 15, 2013

Hi Charles,

Thanks for the answer. Actually (thanks god) we didnt have this problem yet. It was a question that was raised in todays scrum presentation and I wasn't sure with my answer. (I said we should terminate the sprint as I recall from scrum guide).

Your chart is very helpful and by the way it's interesting suggestion to flip coin to decide whether an unaccepted behaviour is a bug or not.

Thanks, regards

09:19 am January 16, 2013

There are two things to consider here. Firstly, should you actually do the fix or not. Secondly, you need to consider the impact of your choice for the sprint.

Deciding whether or not to make this fix will depend upon its urgency and who else is available to do the work. If the skills to make an emergency fix exist *outside* of the Scrum team (for example in a support team) then a case can be made for triaging the defect accordingly, so project work can continue unimpeded. Presumably that kind of set-up does not exist in your case though, in which case it will come down to the Product Owner to decide whether or not it can be admitted onto the product backlog.

Assuming the PO sanctions its inclusion in the product backlog, the next thing to consider is the impact of this on the sprint. Can the team can admit it onto their sprint backlog for immediate action, and without compromising the Sprint goal? From what you describe, you have 10 people on your team. That's a large one by Scrum standards. Only one of them is needed to deal with the bug. With those sort of numbers, frankly I'd expect a team to be able to handle it.

But now there are a couple of other things to consider.

1) How did the defect arise? Can the team's Definition of Done be improved to stop a similar occurrence again?
2) You say that only one of the team members will deal with the bug. OK...but is that because he/she is the only one who *can* deal with it? If so, it looks like you have a problem with a lack of cross-skilling and possible skills silos. On the other hand, if *any* of the developers could be the one to handle the bug, then you don't have this problem.

01:52 pm January 17, 2013

Quoting the agile manifesto:
"Responding to change over following a plan."

11:02 am January 31, 2013

Customer goes first => Branch the source code of your latest release, fix the bug on that source code and ship to the customer.
THEN decide what to do with the bug fix with regards to the current sprint.
Most likely it is going to be so easy to include in the current sprint that you won't have to think much.

We do something similar to this for any release (each release has it's own branch), because some industrial type customers cannot be forced to upgrade to the latest version BUT they require hotfixes in their version.

11:46 am January 31, 2013

We did come across such a situation where we had to work on a hotfix during the sprint. A critical defect had to be fixed as part of hotfix. We were 6 members in the development team. All of the team members worked on the hotfix and released within 7 days and later moved to the regular sprint deliverable' s.

12:38 am December 14, 2018

If any high priority defect raised by user in production, but dev team is busy in middle of the sprint or even very end of the sprint, still we can't keep any high priority defect(say P1) unattended. We need prioritise our work and focus on high priority defect by using dev team's buffer time which was decided during estimation. So sprint will not impacted as well as defect. Hope it helps.

09:59 am December 15, 2018

Ideally these issues would be handled collaboratively, in a way that the Product Owner would communicate the urgency, and the Development Team are respected to pull work onto their Sprint Backlog.

This could result in a trade-off, such as removing other planned work that doesn't affect the Sprint Goal, or changing the way that they propose to achieve the Sprint Goal.

One option could be for the team to agree a policy about when such bugs are picked up; essentially treating them as business-as-usual. The team would then need to consider the likely impact of such a policy, when it provides a forecast for the Sprint.

10:10 am December 21, 2018

Asit, this chart may help you in determining how to proceed.

If you happent o have lots of serious production issues, you should look into the root causes and fix one by one, in order to avoid disruption to your business, customers, and - of course - your team(s). You may also want to allocate some sprint time to handle production issues (if no production issues, said time can be spent fixing bugs, further refining the backlog, refactoring, etc).

11:54 pm December 21, 2018

ilker cikrikcili, your arguments are flawed. 

I mean, there is no way that I can say "no, I'm not adding this item to sprint backlog". And I can't wait the end of the sprint to deploy it.

No changes are made that would endanger the Sprint Goal - Scrum Guide

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned - Scrum Guide

So, the only time your statement is valid is if the fix is acting against the Sprint goal. As scope is clarified and more is learned (like the defect is the system that your team just learned!) you may want to re-adjust the scope while making sure the Sprint Goal is still valid.

There are 10 people in the team and only one of them will deal with the bug. The other 9 should continue their sprint tasks even if I terminate the sprint?

While this could be a fact in your current team. This statement does not reflect the "We" mentatility that is a must for Agile thought process to emerge. It is not right to attribute the bug to one person and the rest to others. I'm sorry but, this is not going to build a cross-functional collaborative team ! And your suggestion of a Sprint variant for the rest of the team and idling out the bug fix effort is not in alignment with the Agile Manifesto principles !

Here is my answer: The whole team should consider whether the effort to fix this bug adds value to the Sprint goal or deviates from the Sprint goal and make a valid decision as a team in agreement with the PO. 


10:33 am May 17, 2019


here are several ways how to deal with unplanned work. In my opinion this is the best illustration you can find in the literature.…

04:27 pm May 20, 2019

Thank you Michael.   That is an excellent article.

01:06 pm December 3, 2021

Here is how the hotfix test and release process are composed at my organization:

  1. The customer reports the issue.
  2. The Dev & QA Team checks whether it's a valid issue or not.
  3. Product Owner creates a ticket in case of a valid issue.
  4. The developer starts working on the reported issue and deploys its fix on the QA/Staging Environment.
  5. QA team starts testing the fix and executes various necessary regression tests to check its impact on the SUT (Software Under Test). 
  6. DevOps deploys the Hotfix to production after getting the "Green Go" signal from the QA.
  7. QA tests the fix on production

And I agree with Uma-Venkata Ratna-Kumar Lekkala, the business flow issues should become priority #1 in the running sprint.

I think this video will be useful for you. There is an explanation of what to do when hotfixes alter your sprint and test plan.


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.