Forums

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

ilker

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.