Hotfix in the middle of sprint

Ilker,

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:
http://www.scrumcrazy.com/bugs

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
ilker

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.

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

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.

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.

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.

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.

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).

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. 

Hi,

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

https://medium.com/agilelab/strategies-for-handling-unplanned-work-duri…

Thank you Michael.   That is an excellent article.

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.