What is the best way to work with Bugs within Greenhopper?

[Brian Carr]

Looking for general information/best practices on managing Bug issues within a sprint. I don't think we are interested in estimating (planning poker) bugs, nor are bugs really mean for the planning board. But we definitely need to be able to include reported bugs within a sprint. What is the best way to handle this?

[Timothy · Accepted solution]

Well, if you think the team has the capacity to fix the bug in a running sprint, go ahead and add iti into the sprint. It will be marked as scope change. If not, you should plan your next sprint and include that into that sprint. The rest of the sprint will then be executed when you think your team can deliever it.

[James Strangeway]

We always try to include QA/Testing in our estimates and therefore try to have time in our stories for bug fixes built in. This way I would create a bug, add it to the sprint and assign it and associate it with the original issue if it is deemed necessary to fix before releasing your sprint, otherwise it could be worked on in a future sprint.

[Steve Harper]

We are also struggling with this issue. Specifically, how are people handling bugs that are discovered by QA during a sprint? Some of them we want to have fixed immediately since we are working on the code already, while others need to be put into the backlog for a future sprint because they may involve touching other code. If we document the "fix-it-now" as a type "bug", there is administrative overhead involved in activating it, linking it to the story, moving it into the sprint, prioritizing, and assigning it. And yet, if we create it as a sub-task of the story (which brings it into the sprint automatically) it messes with our quality metrics. Any thoughts on the best way to deal with this?