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

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

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 3

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.