Scrum in combination with ad hoc bug fixes [duplicate]

Question

This question already has answers here:

How to account for a bug fixing iteration? (5 answers)

Closed 5 years ago.

I worked in a company where they tried to use Scrum but in practice it was hard to create a solid sprint backlog because they had a very active userbase, that used the software 8 hours a day, and because of that, reported many critical bugs that needed immediate attention.

This made me wonder... What is the best way to solve this kind of unplanned workload while using scrum? I saw something about Scrumban and Kanban, but still I do not see how it is possible to give the client a somewhat proper estimate of functionality that will be completed within certain sprint in combination with unplanned work (bugs) that needs immediate attention.

Do I need to search for a methodology that can cope with a unreliable workload or do I need to take a look at other stages within the sotware development process? For example to make sure that the quality process will be improved to reduce the number of bugs and with that the amount of unplanned work?

Answer 1

"[...] reported many critical bugs that needed immediate attention" sounds nasty.

If your team can solve 5 bugs per day and dozens of users reported dozens of bugs which all need immediate attention, there is no way you can do what they want. They simply have to wait, and the higher is their leverage to hurry things, the worse it will be, because rushing will encourage your team to abandon testing, code reviews or pair programming and lead to more bugs.

Moreover, by skipping the backlog and pushing the task directly into the current sprint, you're creating a mess. Developers were working on a task; now they must suspend their work and deal with a new task. This alone is frustrating enough to lower the productivity, but also returning to the previous task a few hours later is painful as well: the person may have forgotten where she was.

Finally, you must be sure to assign priorities in a way that only a small part of the tasks appears to be high priority. I've seen projects where on 100 tasks, 30 were "requiring immediate attention" and 60 were "high priority": in such context, developers are simply considering that there are 30 important tasks, 60 low-priority tasks and 10 which will never be implemented.

If your customer, boss or user is asking to solve a bug right now, the only possible answer is:

We added this task to our backlog and we set it to be a high priority task. We are currently solving 68 other high priority tasks which might take us from four to five weeks. We'll keep you updated.

What if the bug is blocking?

What if the bug should actually be solved right now, because of its severity (such as a user cannot log in)?

• If this is an isolated case, then How to account for a bug fixing iteration? mentioned by Gnat is relevant.

• If this becomes a pattern (like several right now bugs per day), then there is something completely wrong in a way your team is developing the software product.

  If the team is using pair programming or code reviews, if the target code branch coverage is high enough, if everybody on the team understands the requirements, if you do regression testing (through Continuous Integration) and if the deployment is automated (nobody's messing with your servers), this shouldn't happen.

  Again, no matter how well your team is doing the job, bad things may happen from time to time. But if this happens regularly, something is out of control.