3

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?

0

1 Answer 1

6

"[...] 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.

3
  • Thank you for your answer. You mentioned very good points. About your answer to the client. This would be the ideal answer of course but what if the bugs for example would make it unable to work with the system anymore. That would be an issue that cannot be put on the backlog because it needs to be resolved right away. Especially when we talk about web applications and SaaS, it is easier to solve bugs but it makes it harder to postpone immediate attention work because you maintain your own software. Our software was used by different customers as a SaaS application.
    – Bram
    Dec 14, 2014 at 12:36
  • 2
    @Bram: if this is an isolated case, then the question mentioned by gnat is relevant to your case. I was answering specifically about the cases where there are "many" bugs which require immediate attention. Dec 14, 2014 at 12:38
  • thank you for the additional information. It seems in my opinion that we need to take another good look at the overall process and find where to improve quality and make sure that we will reduce the number of 'blocking' bugs before focusing on the process to resolve the bugs. Always better to prevent than to act on it ;)
    – Bram
    Dec 14, 2014 at 12:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.