Details In the ideal Scrum world, no errors occur in shippable code that has been successfully unit-tested; that this is no longer the case in reality, at the latest after a first manual acceptance test, is, I think, more in line with all of our experience.
My question now is: How do you handle bugs that occur during acceptance testing in parallel to ongoing/upcoming sprints? Do you generally create new user stories out of bugs, or do you only track them separately in a bug tracking system?
In the case of new user stories, I find estimating them somewhat problematic, as the effort required to fix bugs is, in my opinion, more difficult to estimate than that required to implement new stories.
Moreover, yes, an ongoing sprint should remain untouched, but what about serious bugs that more or less prevent a meaningful continuation of acceptance testing?
Henrik Kniberg suggests in his book "Scrum and XP form the Trenches" to basically continue with the implementation of new stories, but to prioritize reported bugs. This approach also makes sense to me, but I am still not completely clear about the optimal (organizational) handling of bugs.