how to Handle blocker bug in middle of Sprint
Dear All,
Recently i have an issue in implementing scrum in our company. the case happened as following: in the middle of sprint which it's length is one month, one of our customer raised a blocker bug in our system. and the customer clarify that if his work stop more than 8 hours he will execute a penalty on us. so in our case, we interrupted the Sprint, fixed the bug, tested it and released an increment in middle of Sprint. what is correct practice in Scrum to deal with cases like this.
Have a look at the Bradley Bug Chart:
http://www.scrumcrazy.com/One+way+to+handle+Bugs+and+Production+Support+in+Scrum
Much depends on:
- the decision of the Product Owner regarding what is best for value
- the commitment, if any, teams make towards fixing production defects versus meeting the Sprint Goal
- whether or not the Sprint Goal actually remains viable
- the degree to which technical debt has been incurred and development is sustainable
Thank you for your reply.
as you say, the main reason for that is technical dept. and in many time we found our self in situation that lead us to cancel the Sprint.
The Scrum Team I'm in are currently writing a Service Level Agreement to determine which issues should be taken on directly.
Rather than seeing it as a threat to the Sprint Goal that the team must resist, we expect to see this as a consistent responsibility of the Development Team, which they will take in to consideration when forecasting. Even in situations where doing this work means the Sprint Goal won't be met, the team accept that this extra work is their responsibility and to be treated as a higher priority.
This includes things like patching major/critical bugs or problems with data, fixing recently introduced bugs, and answering stakeholders' questions about the current functionality of the software.
Like anything, dealing with these issues is ultimately negotiable with the Product Owner, but the theory is that this will provide a fairly consistent/predictable level of disruption to the Development Team that it will allow them to provide meaningful forecasts. We also intend to inspect and adapt the agreement, as we learn more about its impact.
Note: Although we've used the term Service Level Agreement, we are not writing it like a formal contract; because our key stakeholders work for the same company, and we expect to have a good level of trust and co-operation.
The Agreement is the Sprint Goal. If a Development Team is able to achieve the Sprint Goal then it should be allowed to add/remove the work as per their convenience, involvement of PO may or may not be required.
Too many times cancellation of Sprint(s) requires a Retrospection - improve the technical practices, Pay the technical debt first, shorten the Sprint cycle etc.