What is the right way for estimating blocked or urgent bugs opened in the mid of sprint

The first thing to do is to gauge the impact of the defect, and the work required to fix it, on the Sprint Goal.

PO  proposes priority, architect and team evaluate the impact of bugs together

Estimating Bug and its impacts should be done during a separate meeting?

PO  proposes priority, architect and team evaluate the impact of bugs together

Does the Scrum Framework have an architect?

Estimating Bug and its impacts should be done during a separate meeting?

 You don't have to arrange an entire meeting for a bug. If it's just a minor thing and has no impact on the Sprint Goal, you can quickly take 5 minutes to do an estimation and discussion on it and place it accordingly on the Product Backlog.

The first step is to triage the bug report. In my experiences, this effort is typically led by the Product Owner but may be supported by someone on the Development Team. The idea is to ensure that the bug report is valid and understand the severity and impact. After triage, you should have an understanding of if the bug is something that must be fixed quickly or if it can be ordered on the Product Backlog for a future Sprint.

If the work is urgent, then it should be brought to the Development Team to discuss with respect to the Sprint Goal. Although the Scrum Guide does allow for cancellation of a Sprint, this often doesn't make sense. Instead, replanning can happen to determine what can be done in the Sprint in addition to fixing the bug. The Product Owner and Development Team can come to an agreement as to how the goal and scope of the Sprint can change to deliver the new work.

If the work is not urgent, it can be refined per the team's standard way of working. This can help the Product Owner determine the complexity and level of effort needed to fix the issue. Knowing complexity and effort can help in ordering the item appropriately on the Product Backlog relative to other features or bug fixes.

For me it depends on when the bug was introduced.  

If the bug is a result of the code changes being made during the Sprint, the development will discuss the impact of fixing it or leaving it for later. If the increment can not be potentially releasable with the bug in existance, it is fixed as part of the original effort of satisfying the original Product Backlog Item. No extra effort is used to estimate the effort.  It is just treated as new information that has been uncovered. If the bug is something the Scrum Team deteremines will not block the accomplishment of the Sprint Goal or impact the potentially releasable nature of the impediment, then the Scrum Team can decide to add an item to the Product Backlog to address the problem and then treat is just as it would any other item in the Product Backlog.

If the bug is reported from Production then an item is created in the Product Backlog and it is handled just like everything else in the Product Backlog. It is refined, estimated, ordered in the Product Backlog, and taken into a Sprint at some point. If the Scrum Team agrees that it needs to be resolved immediately, discussions ensue on how to bring the item into the current Sprint and whether the scope of the Sprint needs to be adjusted.

For me, it comes back to the following questions:

1. Does the defect impact the delivery of the Sprint Goal?
2. Does the defect impact the delivery of a Sprint item unrelated to the Sprint Goal?
3. Do we know whether the defect was introduced during the Sprint, or was it a legacy defect?

Keep in mind that it is inherently difficult to estimate defects, since they reflect something unforeseen and contrary to how we believe the code should work, and scope is unknown (otherwise, it would be fixed).

Dear All,

Thanks a lot for your comments,

You are helping me to become not only a Certified but also an experienced and "right" SM.

The image of bugs and bug fixing can vary.

1. In DOD we have defined that User Story is done, when all the bugs related to it are resolved and closed. So, in this case DOD also is affected when the Bug is being prioritized and put into backlog., isn't it?

2. I have suggested to my team not to estimate the Bugs as they are part of their effort put in the US estimation, isn't this a good practice?

3. If am not mistaken the Scrum Guide does not make it mandatory to estimate BUGs as well.

1. Yes, Definition of Done will be impacted by this.  However, there could be times where a bug may not affect the ability to release.  What I have always done is suggest that "all defects are addressed."  Addressing the defect would mean that

• discussions have occurred and it was deemed ok to ship with the defect
• an item is created in the Product Backlog to address the issue at a future date

2. As long as the defect is going to be fixed in the current Sprint, I feel that statement is true.  However, if the defect is moved to the Product Backlog it should be treated exactly as any other item and match the Scrum Guide's description of items that are found there. From the Scrum Guide

Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".

3. Based on the previous quote anything that exists in the Product Backlog should have an estimate as part of it's attributes. If a bug is found in the Product Backlog, it should contain all of the attributes that any other item in the Product Backlog does. If you want to be technically correct, the Scrum Guide does not make it mandatory to estimate User Stories because the Scrum Guide says nothing about User Stories.  It just refers to items in the Product Backlog.  What kind of items are there is entirely up to your organization.  But they should all have the same attributes and be treated equally.