Is it a OK for a team to commit to stories that are for fixing bugs? Should the Solution Owner create stories for a team to fix bugs? Over the past couple of years I have noticed teams struggle with this issue. These questions have been very difficult for teams to answer. There can be many reasons for this behavior. The one that has been most prevalent is that teams want to be able to prove to the customer that they did something in a sprint, so they want a story for everything they do.

For instance, many teams insist on having a story for fixing bugs. In my opinion this should not be done! I am not saying that you do not want to add a story for fixing bugs to your sprint tracking tool. You definitely want to track how much time the team spends on fixing bugs each sprint. But, the Solution Owner should not have a demonstrable story for fixing bugs available for the team to select as part of the sprint backlog. Fixing bugs is a TAX on the team for every sprint! In fact it is part of the support tax the team has every sprint. Why do I say this? Because a bug is some piece of functionality, previously delivered to the customer, that no longer works. The team has already delivered the functionality in a prior sprint, the customer has already paid for it and expects it to work. The customer should NOT have to pay for that functionality again. I am not saying that you give something to the customer for free. What I am saying is that the stories demonstrated during a Sprint Review should NOT include items that are part of the support tax.

At the beginning of every sprint, the Solution Owner and the Team should go through the issue tracking tool to determine 1) if the team is over its high water mark for issues, and 2) what issues will be fixed during that sprint. A story should be added to the sprint tracking tool a team uses with the bugs as tasks to that story. The team should then WAG (estimate) the tax applied to the sprint by fixing the identified issues. this should include adding estimated hours for the tasks in the story. After this is done the expected velocity should be reduced by the estimated tax. The story’s WAG (estimate) should also be made zero. After a few sprints following this process it will provide the team with metrics around its tax. This will then lead the team to be able to more accurately identify its velocity.