How to deal with hotfixes keeping the scrum methodology

Question

My team works with scrum methodology.

However, during some sprints we have hotfixes that have to be developed as soon as possible, so we treat them in the current sprint, and consequently we have an impact on the sprint goal in which we are engaged.

These hotfixes have to be corrected quickly, without time to create a task in the backlog or without previous refinement.

Which would be a good way to keep the scrum methodology, while we add constantly these hotfixes to the sprint?

Answer 1

Jeff Sutherland, the inventor of Scrum, developed a pattern called 'Illegitimus Non Interruptus':

Explicitly allot time for interrupts and do not allow more work than fits within the allotment. If work exceeds the allotment, abort the Sprint. - Scrum Patterns Group

You will likely have historical data on how much time you should allot. Look at frequency of hotfixes per Sprint and the time it takes to produce a hotfix. If producing a hotfix can cause a Sprint to fail (Sprint Goal not met) then consider creating a new (smaller) Scrum Team that can be protected from hotfix demands.

When no interrupts occur there will be temptation to pull more Product Backlog items into the Sprint. Don't. Instead, enjoy the very real benefits from finishing early:

after analyzing data from dozens of sprints with multiple teams. The teams that finished their Sprint early accelerated faster. This was the root cause: finishing early. It allowed teams to think more clearly about what they were doing — to remove impediments; to pull forward backlog from the next Sprint; to develop a winning attitude - Scrum Patterns Group

Also, you may want to take a deep dive into your technical debt and your quality in general, to determine whether you can work on reducing or eliminating to the need for hotfixes.

Answer 2

If I understand you correctly, I feel like there are other two questions that you need to answer:

• Why hotfixes happen so often?
• Can you create a plan to address the root cause instead?

There seems to be a smell of some missing tests (or in general, as onedaywhen already mentioned some technical debt).

While you figure out the root cause and plan to mitigate it, it might be good to separate the process for addressing hot fixes from the actual tasks of the sprint or at least decide on the tasks that you are definitely going to deliver and rotate people every sprint that will address the hot fixes. This helps to keep at least one part of the team focused on the "key" sprint tasks.

Comment about this part:

These hotfixes have to be corrected quickly, without time to create a task in the backlog or without previous refinement.

You need to log them along with the relevant details to solve the problem. They seem recurrent and the negative impact on your project seems significant.

A proper log will help you understand:

• What's the actual problem
• How much impact is having?
• Who can help you solve it? (is it only technical debt? perhaps there's some requirements miscommunication with the other departments for example)

Answer 3

You have no choice other than fixing them -- it's just required by business.

So, best you can do is to count statistics of how many such bugs-per-sprint you usually have, and include special timebox for such bugfixes on your sprint planning.

If there is a sprint when you don't have any issues, and you don't know how to spend the timebox better, then you have following options:

1. Have so-called "stretch features" -- i.e. features which we include to sprint backlog, but don't commit to complete them in this sprint -- we include them just to not sit idle waiting for next sprint.
2. Spend the time on non-features such as refactoring, automatic tests, etc.

Which one to choose should be decided by your team and customer.

And, ofcourse, try improving your quality so that there would be less hotfixes :)

And Niels is correct -- it seems like a specific case of this question.

Answer 4

Two possibilities:

• Simply plan them in as you would with any other methodology. Reserve a certain amount of time.
• If you tend to have significantly more hotfixes than normal work over a longer period, it may just well be that SCRUM is not the correct choice. If that is the case, a more generic (Kanban) methodology might be more appropriate. Kanban can be very similar to SCRUM in practice, basically you just skip the fixed sprint cycle (you still have a cycle, for example for retrospections and such, if you so wish, you just do not assign tasks to cycles).