Does the user have a bug that prevents their work from continuing to be reported for development and want to commit to the new bug and stop the development of the platform?
When is it okay to add this bug to the next sprint?
What is evaluated in this decision?
The size of the damage that the bug causes determines the urgency.
Assuming it is an application running and being used by users and this bug in some way prevents users from using the system - in some main feature in> it is reasonable that the development stops the other features and focuses on solving this situation. I imagine the damage it would be to your client, if users start complaining.
If this bug is in a feature not used much, something in the backoffice , for example, the bug will be resolved and you could move it to the next sprint .
If the system is not in the air, bug is not causing a real problem and may have been discovered during the tests, which will not cause any damage. I think it can be easily pushed forward.
These are examples and suggestions, it is not you should make these decisions yourself, it is always the Product Owner that has the final say. You should help him evaluate the situation by making it clear that this fix can take time from another possibly more valuable feature. If it still still does decide that bug should be treated with priority, this is what should be done.
The goal of sprint planning does not change due to the appearance of bugs, that is, everyone will continue working to clear the backlog of that sprint.
During the "Daily Scrum" the development team will inform the "Scrum Master" about this bug and its severity. The "Scrum Master" in turn will present the fact to the "Product Owner".
The "Product Owner" will judge the value generated or lost in the product or delivery depending on the bug and will define the correction by placing it in the backlog in the necessary order / priority.
