How do you handle a pool of unrelated small bugs in Scrum?

Question

We've recently adopted Scrum on the job and are running into trouble with a bunch of tiny bugs that appear after code has been accepted. These include things such as spelling errors, and other single line fixes. To create stories of size 0.5 for every little thing seems like a waste of time. It takes more time to write the story and point it than it does to make the fix. If there were only one or two of these per sprint, it would be easy to just fix them and not worry about creating stories for them. However, if there are 10 or 20 or more because the application is large, this can start to add up to significant amounts of developer time that aren't being accounted for via Scrum. While it may be easy to say the QA staff and product owners should be more thorough before the original story is accepted in the first place, I'm the developer so that is essentially out of my hands.

A couple imperfect ideas we've come up with so far:

• Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload
• Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work
• Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.

Any suggestions?

Answer 1

Your third answer is the best method. A sprint is simply a commitment by the team to complete a specified amount of work in a defined period of time. If you're accepting additional work in the middle of the sprint, you're deviating from that original commitment by working on things that were not committed to by the team at the beginning of the sprint.

Here's what we do:

• All stories within a sprint must be defect free in order to be considered "done"
• Any defects that are found during a sprint for a previously completed story are logged and put into the backlog. They're estimated just like anything else and prioritized by the product owner. If a product owner prioritizes new features over defects, they're choosing functionality over quality and vice-versa.
• We don't assign story points to defects, but we do estimate every defect as it gets accepted into a sprint as part of planning. The team shouldn't get credit for broken functionality, but by the same token the time it takes to fix them needs to be recognized -- this accomplishes both.

Here's the problem with your other solutions:

Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload

Again, see above. You want to avoid empty buckets of work that can be filled during the sprint. This defeats the purpose of a defined commitment by the team. How can the team commit to something they don't know about or haven't estimated?

Plus, this can easily spiral out of control into a product owner that will "design by defect" by filling that bucket with nice-to-have functionality that is really masquerading as defects.

Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work

This sounds strange. The team should be accepting work at the beginning of the new sprint planning, not at the end of the previous sprint. Additionally, this will really skew your velocity over the long term. Scrum refers to Product Backlog Items, not just Stories, so there's nothing to say that you can't include defects as PBI's.

Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.

You make an interesting point and we had some concern about this as well. However, that 1 hour fix (regardless of how quick it is) may not be time well spent when stacked up against the other things in the backlog. The bottom line is you want to push these decisions off to the product owner and give them the freedom to prioritize EVERYTHING the team spends effort on.

Answer 2

Who handles the support for the code you push into production? If your team does handle support requests then these typos and other cosmetic problems fall into that category and get handled appropriately. If not, then you may have to have the occasional sprint be kind of like a "patching" sprint where no new functionality is added but many old things are fixed and technical debt is reduced to a reasonable level. Or combine a bug of the little bugs into one story of say "Fixing all typos on the site" for an idea.

If you Google up "technical debt" or "broken windows" with Scrum to see how others handle these things there may be other ideas out there.

Technical debt is

Answer 3

I firmly believe that a process is only as good as it's ability to improve a situation. The process should work for you, not the other way around.

If following the Agile Scrum process to the 'T' is doing more harm than good, in this situation, then it is time to find a better solution outside of the Scrum process.

We have created a mini 'QA' sprint that is tacked on to the end of every sprint. It is after code complete but before release. In this short time period issues are carefully scrutinized and can be approved for inclusion based on risk and criticality. Issues fixed in this time period have some extra level of a custom review process, but work largely outside of the defined Scrum process.

Answer 4

I have had the following policies succeed in my projects:

• Defect correction is always prioritized over feature development. The target is to have zero open defects at all times, valuing 100% working features over almost-working features.

• Defects can and should be fixed as soon as they are found. A ticket needs only to be filed if the defect is found by some non-developer or the developer finding it cannot fix it instantly.

• Defects that require architecture-level changes to the code base have the architecture tweaking part logged as a story and estimated & planned to some upcoming sprint. The defect status is set to be pending on the story implementation.

• Sprint backlog is protected from external changes, but the team itself may introduce new stuff in the middle of a sprint that is required to meet the zero defects at all times target.

• If a defect is not worth fixing (based on some rudimentary cost-benefit analysis), then it simply ignored to prevent won't-fix open defects from polluting the issue tracker.

Prioritizing defect fixing over story implementation will hit your velocity from time to time, but it's ok. In the long run, your efficiency in implementing stories will increase as the code base has only a little technical debt in it.

Answer 5

Have you identified during your retrospective the cause of these bugs? Are you using engineering (XP) practices i.e., doing TDD - test driven development, autoamted functional tests will daily full regression testing along with pairing and story cards with acceptance criteria.

When a defect is found, is the root caused identified and is an automated unit and functional test added to your test harnesses to catch such a defect should it occur again?

From my understanding, your defect rate is too high. If one does TDD and full functional regression tests at least daily, it is not uncommon to reach zero defects during UAT.

In the short term, you can charge the team x number of units/ points of work to fix the defects (look at your past iteration and if it takes x number of hours per iteration to clean up the small bugs, subtract that time from your team's capacity.) Longer term, focus on the root cause and improve your team's engineering practices.

From measuring the cost of defect fixes, we have seen the following relationship. If a defect cost 1x during development, it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix when in production. By writing story cards with acceptance criteria, pair developing, test driven development and automated functional test with at least daily full regression testing, you will improve quality and reduce cost significantly. As a result, you will not need to subtract any time from your team's capacity which will improve velocity.

Answer 6

This is a fine example of the strong need for sound engineering practices in Scrum projects.

"[we're] running into trouble with a bunch of tiny bugs that appear after code has been accepted"

This suggests that your "definition of done" is not strong enough.

"These include things such as spelling errors"

Do these spelling errors appear on the UI? Whomever is spotting them after the code is accepted should be spotting them before the code is accepted.

The thing to do with defects is 1) fix them right now, 2) instrument the system so that similar defects will be caught earlier next time and 3) improve your process so that the kind of error that lead to the defect is less likely to occur in future. These are all technical issues.

Answer 7

If the bugs cause you to stop working on the sprint goals you still can decide to cancel the iteration and replan. But this is a quiet hard decision.

Answer 8

Hi there, what we normally do, in case the Bug are unrelated to what you are developing, or let's say any other "unrelated" activity happening during a sprint, is to create a "Contingent".

It is basically a certain amount of time that will be removed from your "capacity" for a sprint, and will be dedicated on demand to do activities outside of the sprint goal. This works the following way:

• Daily the team focus on the Sprint Goal, but has a "buffer" of time (the Contingent) to take care of external issues. At the Daily stand-up the PO may present daily incoming issues, and the Team Members that completed a Sprint task (so there is no interruption) will eventually take one of the issues to fix.

• The time is that booked on the contingent, that when comes to an end will have to be closed.

• The Team has the right to communicate to the Product Owner that the time in the contingent is over, and that if he wants them to keep the Sprint commitment, he will have to decide whether he want them to do so, or continue running after daily issues, giving up some value out of the Sprint.

It always worked out to be a fair deal ;-)

We use it for the following: Bug and Maintenance of the live product (5-15%), preparation of the upcoming sprint (10%)...

HTH