Too small for a user story – bugs, fixes and support

Some things are too small for the overhead of a user story, still they must be handled during the sprint effectively. I suggest a small taxonomy to classify them and also what to do with them.

With a vocabulary for small things daily Scrum becomes a lot easier as the team have working agreements on how to deal with each one of them.

Bugs

Bugs are of one kind only: bug. There is no high priority bugs, all have the highest priority, higher than user stories. Bugs have a swim lane on the board above the ones meant for user stories.

With that said, it is of paramount importance to have a very strict definition of what is a bug. It is only a bug if any of these applies:

  • Information is corrupted or destroyed by logic errors in the software.
  • Usability is so bad that it tricks the user into entering wrong information, thus making information corrupt.
  • It is a security breach which threatens to corrupt information

The common denominator is the corruption of information. After all, that’s is what we do, information technology.

Once you have identified a bug, put it on the top of your planning board. How fast you react on such a change in the priority is up to you but if your process is working, the next day would be the latest.

The first thing about bugs is to write a test that exposes them. I’m not saying that because I do TDD, you would like to have a test anyway so that you feel confident that the bug is fixed. The only thing worse than a bug, is a bug that comes back!

If bugs stops you from delivering new features, first stop producing bugs. A sprint filled with bug fixes delivers zero business value, unless you consider getting a kidnapped person back as a kind of value delivery.

If you love bugs a lot, collect them in a bug tracker. But in either case, do count them to see if there something you need to follow up.

Fixes

Fixes are small things like bad grammar or spelling in a user interface. No information is corrupted but it certainly does not make you look good. Annoying, is a word that comes to mind. Meanwhile, you can’t reasonably write a story that takes care of it. “As a teacher of mathematics, I want the question dialog be spelled correctly so that I don’t get a heart condition”.

Fixes go to the board as well, to their own spot. I suggest you grab fixes when you’re done with a story, before moving on to the next. They are often cheap and gives you a quick fix of satisfaction.

You should count fixes too. If you have a lot of them, consider tuning your process. Is there a sloppy attitude somewhere or is there a lack of communication between people? Is there a common root cause to many of our fixes?

Support

Support issues are when the system works as designed but there is still a need for something. E.g. database reports available only by writing custom SQL or explaining an integration point to an external party.

Support takes a delicate touch when prioritizing.  Usually the user need is imminent and the value obvious, thus requiring high attention. Still, there are user stories to handle. Of course, PO must be in the loop.

If you have too many support issues, you need to analyze them and find ways to bring the number down.  Again, count and visualize.

Summary

Little things like these can be frustrating and sometimes take a long time to deal with. By classifying them, visualize and keeping statistics, it gets a bit easier to live with them.

5 responses on “Too small for a user story – bugs, fixes and support

  1. Hi Per,

    very interesting post. I do agree with both bugs (they are evil) and fixes (they are lame). For the support part, I’m confused.
    If your backlog / queue is filled with US or something in a BDD-style, the support issues are nothing more than a new story in your backlog / queue. The team have to collaborate with the PO for prioritizing but first they should “estimate” (no #noestimate troll intended).
    Given the context (fixed-date and scope sprint or more pull-driven production) the PO can reorganize the backlog / queue for the next sprint or next in line.
    My point is you have to visualize this evolution. If you don’t, how the team would measure it’s velocity ?

    1. You could of course consider a support issue something to add to your backlog and prioritize. Still, it is of a nature that the need is imminent – you really need to do it right now. It is an unplanned task you did not anticipate.

      When you measure velocity, there will be some unplanned tasks each sprint that hampers velocity. So you keep track of the number of bugs, fixes and support issues you have. If they are hampering velocity significantly, you must find the root cause and deal with it.

      Support issues are a bit special since they don’t change the system, they are just part of the operation of the system. If we immediately react with a change in the system to push, say, invoking a report onto the users, we may be doing something that is not needed. It was a one-time need only. On the other hand, if we keep doing the same thing over and over again, something is missing in the system. Maybe we should get rid of these repetitive support issues so we can focus on other things?

      Support issues are a kind of feedback on how users are using the system in production.

      These are my reasons for treating them differently than user stories.

  2. Thanks a lot for this response.

    What I understand now is that a support is a really small change, but with a lot of value.
    Then I do agree: the team have to do it, as long as there are not too much (the count and visualize part).

    I’m though a little bit afraid -because of the maturity of the firm I work in- that this class of service become an excuse to reduce the quality of the “specification” part.
    So, once again: visualizing and counting, with an inspect and adapt loop are keys.
    Very useful =)

  3. I just like to stress that with support, I mean no change to the system. Changes to the systems are either bugs, fixes or user stories.

    Support is something you do because you have specific knowledge and access rights. It is an indicator that some function may be missing in the system.

Leave a Reply to Stéphane Wojewoda Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.