Have defects when sprint running, what should I do?

See the Bradley Bug Chart: https://www.google.com/amp/s/scrumcrazy.wordpress.com/2018/09/22/one-way-to-handle-production-support-and-bugs-in-scrum-bradley-bug-chart/amp/

I'd suggest that it is up to the Developers themselves, rather than you, to decide and adjust their capacity. They should also be encouraged to improve their Definition of Done so future quality improves.

I try not to load the team up to 100% capacity if there is an element of potential BAU bug fix to come in.

I say to the team happy for them to work on stuff outside sprint and help other teams with issues/problems/queires/etc but within reason. When it starts to look like it will affect the sprint goals then we start having discussions.

I find the more freedom and ownership you give the teams the better decisions they make and the work that usually would have been hidden starts coming to light.

Once you start getting a picture of the work outside of sprint goals then the team can come up with potential better ways to deal with them in the future, whether it be better DoDs, Test Coverage or capacity allocation during sprints.

Whenever there's a critical issue from an operational system, it needs to be triaged. The Product Owner is in a good position to answer the early important questions. Is it a bug? Is it critical? If the answer to both is yes, then it's something that the Product Owner can consider bringing to the team. If it's not, then it should probably be ordered on the Product Backlog, refined, and pulled in at the appropriate time. I will say that I can't recall seeing a feature, regardless of how important it is, be something worth interrupting the team's plan for, but that doesn't mean that such a feature or modification isn't out there.

Once you've made the decision to bring it to the Developers, you still have committed to fixing it. Perhaps there's insufficient information to reproduce it, so even if it's urgent, the Developers' time could be better spent working on things that are more well known. In some cases, the Developers may know of a suitable workaround that would decrease the urgency of the issue. There needs to be some level of refinement of the work to make sure that the desired state is clear, and the team should always have allocated time for refinement each Sprint.

After the Developers had a chance to understand the work and figure out the impact, they can have conversations with the Product Owner about trade-offs. What is the impact of bringing this work into the Sprint? What won't happen if it's brought in? Will the Sprint Goal be in jeopardy? How does delivering this work stack up to achieving the Sprint Goal or completing other planned work? The team, as a whole, can make the decision on what to do.

If supporting production issues is a regular occurrence for the team, it may be worth the time to allocate time to this type of work at Sprint Planning. The team can reduce capacity based on historical information about this kind of operational or support work. I'd also recommend that that team perform deep dives using root cause analysis techniques about the most critical issues to attempt to understand what caused them and how to prevent them from happening at their source.

Hello Minh,

Let me explain by example or scenario, so you can relate to your situation and can take a decison.  

Obviously, it is the collaborative work by PO and Developers. They have to analyze the impact of defects and the importance of defects. Some, defects/bugs are dependent of existing sprint work, so it should be fixed immediately. 

Some defects/bugs are not disturbing the existing sprint work, so we can add them into Product Backlog and can take them into the next sprint.

Some, organizations know that these types of defects/bugs will come, so they are keeping buffer time in a sprint to solve it. So, if you will think about these things in advance then you can manage the capacity of your team in advance on the sprint planning day. 

In some organizations, some dedicated support members are working day and night to solve defects/bugs. So, it depends on how you are managing your resources and how much your product/project is complicated. 

On the same line as Bhavin mention, it's best to have a separate story to handle the prod inquires/incidents , in your sprint sized as buffer, and based on analysis done...PO can decide, when to take the further action after knowing any workaround available.