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 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 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 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.
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.