Can you pull a "Bug" into an active sprint where there is capacity to fill?

That is a fairly vague question. It might help if you gave us some more information around why you are asking it. 

But to answer your question that is up to the Development Team to decide since they own the Sprint Backlog and the commitment to the Sprint Goal.

I agree with Daniel, it's up to the Developers. A few questions at a minimum that should be asked:

• Would taking on the bug impact the Sprint Goal?
• Would it interfere with having a Done Increment by the end of the Sprint?
• Would we (the Developers) have to cut any corners to fix the bug?

In general it is best to limit changes changes during a Sprint. The Developers need time to focus. And the Product Owner cannot simply be an order taker, pulling in every request from a stakeholder and disrupting the Sprint. If it can wait until the next Sprint the product Owner can certainly change the order of the Product Backlog.

All the best

Can you pull a "Bug" into an active sprint where there is capacity to fill?

What does that defect mean for the Definition of Done? Perhaps it is inadequate and needs improving, and therein lies your answer.

Defy "Bug"...



If it's a bug found in production of the type Blocker, Critical or High (without a satisfying workaround), it goes through the P.O. directly to the active Sprint with the highest priority and if there isn't any capacity available in that Sprint, the P.O. and Developers will discuss and remove a workitem from that Sprint to make capacity.



If it is a bug found in production of the type High (with a satisfying workaround), Medium, Low or Cosmetic, it goes to the P.O. to triage which bugs go to the Product Backlog and which will not be done.



For any other bug, it is up to the Development Team, because they own the Sprint Backlog.



It all comes down to common sense and communicating to the correct persons.

If the bug is already makes entry in product backlog as a candidate for future sprint , prioritized by PO and refined by team, if there is no impact on sprint goal and there is capacity (assumption, one development team member cancelled his/her leave for 3/4 days) then in this case this bug can be pulled.

And for any last minute production bug, critical bug ,PO , stakeholder requested change can wait for prioritization and refinement. 

For resolution of production critical bug/blocker there are support guys, which mostly working in Kanban - WIP .

Kanban - WIP is the best for handling extremely changing, un predictable environments -like support, where focus is to handle the changes efficiently.

WIP is the best way to handle changes efficiently. WIP limits can be decided based on with or without blockers.

If the bug is a result of testing an In-sprint story, then the team needs to fix it inorder to mark the story as Done. It is a part of the sprint If the team is unable to fix the issue, they can decide to split the story logically (horizontal spilt) and complete what is possible in that sprint.

If the bug is a production bug, pick only based as per its priority. If the team has capacity they can take the decision to pull it in. According to me, try not to take any new production bug unless it is a Showstopper or critical. If the production bugs are common in your project then try to have a separate set of team on it. Kanban works well in maintainance/Support projects.

This is a wrong question. What can stop you from pulling it? Scrum Guide? Jira settings? Your Scrum Master? ;)

Of course, if there is a critical bug on PROD you need to address it right away. 

"Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions" - Scrum Guide 2020

Sprint Retrospective can be a good occasion to talk about it. What have we learned? How can we prevent it in the future? Should we adjust our DoD?