Product Backlog:
- Works as an effective way to group like issues together, creating coherent 'Use Cases' for future Sprint work.
- Gives the customer an opportunity to prioritize. Putting new issues automatically in the next Sprint takes away that prerogative of the customer.
New issues should go into Product Backlog; issues should not be automatically added to current Sprint nor moved to the next Sprint or if it's not newly introduced.
"New issues" are basically any issue that the team agrees is outside current scope, particularly if there is no existing user story/use case for it already. The scrum master should do this.
- Issues introduced that are from a change/fix made in the current Sprint should be handled in the current Sprint if possible.
- Pre-existing issues that are just now discovered should be moved to Product Backlog for consideration for future release.
(This is to help minimize the additional churn created by taking time to make a fix, test and then document. Sprint-over-Sprint releases would get to be more planned, repeatable process. A potential problem is that developers take time to clean up small quick fixes that actually take QA longer to test and document, keeping developers from planned work and testers from planned testing.)