How to plan a sprint if critical bugs from users come up during the sprint?

Question

Agile

After the start of the sprint, it happens that critical bugs from users pop up. Accordingly, these bugs are corrected, because of this, features are handed over later, and the release date is shifted. And this happens even if the sprint includes time for a bug fix.
What is the best thing to do in this case? Pledge more time?
Or divide developers, some correct bugs from users, others make features?

Answer 1

Better - greatly reduce the flow of bugs so that there is no need to divide developers. It makes no sense to make new features if the ones already made are either crooked, or incomplete, or poorly done - by doing this you dig a hole for yourself.
When the flow of bugs is small, then they fit into your focus factor. If you need to fix something urgently (for example, the client is not ready to wait for the end of the sprint), then it is better to use a mixed process, for example, scrumban.

Answer 2

dividing developers is an unsubstantiated idea - you won’t be able to properly balance the load between them, there will always be some developers idle - there will always be someone who will do part of the work more slowly or faster, more divisions, more such things.
again, I’m sure that it’s best to fix bugs for the one who made this functionality, at least he doesn’t need to explain what is there and how it works.
========
About sprints and bug fixes.
There will always be bugs, start developing the product assuming that there are already bugs in all nodes and modules (this is how it actually happens), this will immediately change the approach to development - by switching to schemes in which the product works regardless of failures and bugs in individual modules.
As a result, you will always get a working product, regardless of bugs, in which you can start separate sprints at any time to improve the quality of its work (reduce the level of bugs).
In the current sprint, you work only on the current assigned tasks - this is the law (do not take anything else). The sprint deadline is fixed - what was done was done, everything else is transferred either to another sprint, or is thrown out altogether.
This is the whole point, otherwise what's the point in these sprints if you just sit there and pick some bugs from the previous stages.

Answer 3

Divide developers and only accept critical bugs within a separated workforce.