Skip to main content

Blocking-release defect - how the team should handle that?

Last post 05:39 am April 16, 2019 by Erez Morabia
4 replies
09:57 am April 15, 2019

Dear forum,

I have a mature Scrum team part of my engineering group. This team is self-organized, and there is no line-manager assigned for this team. The team went a long way in their agile journey – they pick up their own PBIs, estimate them, and implement then with a team ownership.

In the last retrospective meeting, they raised an item: “the traditional team leader used to handle crises cases – when blocking-release defect arrived towards the release date, the team leader was responsible to choose a specific person, stop him/her from what they are doing, assign them the critical defect, and make sure the defect is fixed ASAP. Today, when the PO prioritizes defect as critical to be fixed (sometimes needs to be fixed within the same day), we feel the traditional team leader role is missing, as we didn’t come up with a good procedure to handle that situation”.

Before I approach the team and start asking powerful questions, so they will come up with a procedure that suites their needs, I wanted to ask the forum which procedures your teams came up with for handling “critical-defect fix-in-the-same-day cases”. 


11:12 am April 15, 2019

Have the PO and team been discussing this together? Is it worth the wait for the customer if this critical issues blocks other items to be created/released are done at a (I'm presuming) slightly later point in time?



03:28 pm April 15, 2019

If they are truly self-organized and self-managed then I wonder why this even came up? To me that is actually an indicator that they still have work to do.  If they can self-manage on the "routine" they should be able to identify what to do with the special cases. 

My teams treat these kind of things as they would any kind of blocking issue encountered while doing a Sprint Backlog item.  It is brought to the team, the team then discusses and reacts. The work being done is discussed during the Daily Scrum because it could have the potential of putting the Sprint Goal at risk. There have been times the entire team dropped everything to work on an item as they felt that was the most efficient way to get it done.  Other times, 1 person will pull away and work on the item.  It is entirely up to the Development Team to determine and it is usually done on a case-by-case basis. I have used the Bradley Bug Chart as an example to the teams for a starting point in finding their own methods. It works pretty well even if you decide to use it as your process but as with everything you should make sure that it fits well into your organization. 


05:39 am April 16, 2019

Thanks for the feedback. The team is following Bradly chart more or less. I was talking about mid-sprint critical defect that comes from outside of the team (from external independent testing team, from alpha environment, from production, etc). 

I agree with Daniel that they are not fully self-organized – I guess self-organization is a scale, not a black-white thing. Daniel’s example is what I was looking for. I won’t copy-paste it, but rather let the team self-organize around a solution. Thanks.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.