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.