Hi,
we do Scrum and commit to a sprint goal. Now, if we find bugs during a sprint we don’t know what to do with ’em. Shall we include them into the current sprint? Shall we put them onto our backlog? And how shall we deal with estimating them?
Any ideas highly appreciated!
Find the answers below in the Comments
Agile Web Operations 
I agree that for bugs that just get uncovered during new development, the best practice is to get rid of them immediately. The longer a defect goes, the more expensive it becomes for the company. If that means less functionality or a thinner slice of functionality in a sprint then so be it. Eventually as your team matures they will start to anticipate those types of problems and plan better during the sprint planning. (ideally!)
If you work on a large product like I do, then you may also have defects that come from software that has already shipped to your customers. In that case, we utilize a defect support bucket concept.. the size of this bucket is based on history of the previous sprints.. Yes I know in the ideal world, customers wouldn’t find any bugs we have missed but unfortunately no matter how much TDD or automated tests we use.. those users STILL manage to find things we just didn’t think of!
LikeLike
The short answer is: Deal with them immediately by putting them on top of your backlog. Do not estimate them. Fixing bugs will decrease your velocity. This will show you the cost of bugs and gives you a reason to avoid them in the first place by investing into test automation.
An interesting discussion about the topic is here: http://www.agileforall.com/2010/05/05/agile-antipattern-sizing-or-estimating-bug-fixes/
LikeLike