Skip to main content

Blockers vs. On-hold?

Last post 01:56 pm September 22, 2022 by Jack Leon
11 replies
08:46 am October 17, 2013

Hi,



I wanted to get some opinions on the topic of blocked tasks vs. tasks that may simply be on-hold. I started with a new team that is also new to agile. I have noticed that quite a few tasks are put into "blocked" status, and these tasks stay blocked for several weeks, sometimes months. In my previous teams, when something was blocked, it implied a sense of urgency and would need to be resolved asap. Here, because so many things are blocked, there is no sense of urgency in resolving those issues. For example, if a particular task (task A) can't be finished until task B is done, task A is marked as blocked. I understand why it is technically blocked, but I would have marked it as "on-hold" since really this is a dependency and not a blocker. So I'm wondering what peoples thoughts are. Should only urgent impediments that need quick resolution be considered blockers? Should items be marked blocked if it's preventing resources from progressing? But if they can work on something else, should these tasks really be marked as blockers? Should only tasks in the current cycle be marked as blockers?



Thanks for any input!


09:35 am October 17, 2013

I think it is best to separate internal impediments from external ones.

An external impediment is where a dependency exists outside of the team, and the team are unable to progress an item until work outside of their control is done. These impediments are serious because they indicate that the team has accepted work that they are not in a position to complete. They do not own their process. The Sprint Goal is at risk and, for the affected items, the team cannot meet their Definition of Done. This is a contra-indication to agile practice and it is essential that this matter is resolved no later than the Sprint Retrospective.

An internal impediment is where a dependency exists inside the team. It could be that a team member is assisting another, for example, and that the item he or she is working on is in delay. This is less serious because it means that resolution is within the team's control.

There are various ways to flag these blockers. For external impediments I use day-glo post it notes with BLOCKED in marker pen, then slap it on the index card and thus make the situation as clear as possible. For internal impediments I coach team members just to turn the card upside-down.

Blockages that span multiple sprints are interesting. These have implications for product ownership. They beg the question, is this work really wanted? How does it relate to the Sprint Goals that are being set? Should the item be binned altogether?

Ironically, some long-term blockages are due to delays in getting responses from customers themselves, especially with BAU changes. That happens a surprising number of times and my solution is to set a rule to avoid the waste that is incurred. If an item is blocked because the customer who raised it has not responded for X days, then it will be removed. I keep a record of how many times I have tried to contact them and the notifications/warnings given. The customer must then resubmit their ticket request if they still want it, and it goes to the bottom of the backlog. Certainly that's the way I've run things with BAU Kanbans. I can usually get support from senior management if I explain what it is I am trying to do in terms of the value chain.


12:10 pm October 18, 2013

Thanks, I never thought of it that way, but it makes sense to separate internal vs. external impediments.


03:50 pm October 18, 2013

I like how @Ian has broken this down.

In addition, I would just write a small note on how one classifies "blocked tasks" and interprets them.

Just as everyone should know what "Done" is, consider the categories of the Sprint backlog a part of the information radiator -- everyone should be able to know what its implying. Do check with the Team what makes sense. If there's a category that implies "needing attention within this Sprint" etc. then ask the Team how to capture that?

As a test, consider someone from outside the team come in and try to interpret this, as long as they're not a threat to the Team. They don't even have to be a part of an Agile team within the organization. If they get it, perhaps anyone new coming on board will grasp this quickly.

Hope this helps.


12:31 am October 25, 2013

>>>>I have noticed that quite a few tasks are put into "blocked" status, and these tasks stay blocked for several weeks
They shouldn't be staying in the blocked status for even days let alone weeks. If Scrum is followed, the highest priority items are identified by the Product Owner for a Sprint and it naturally follows that the team works on tasks related these highest priority items.
If the tasks get blocked then you would naturally not be able to achieve your Sprint goal and this would impede the progress of the team. These would have to be brought up during the Scrum meetings since that's the forum for inspection.

It is then upto the Scrum master to attempt to facilitate a resolution and if this can't happen the Product Owner has to be in the know that the Sprint goal is under threat.

I have very rarely seen a Product Owner shift priorities of items just because they are blocked and ask a team to work on something else. If an item is high priority and it remains so all efforts have to be made to complete it. Remember that any item can be continued in the next sprint provided it still remains a priority. Tasks related to this item may have to revisited and in some cases work already done for an item can be reused.

At the end of the day, the best way to analyse where your team stands is to check whether they have a completed increment of functionality which meets the definition of done at the end of the sprint.
If the answer is no, then all the work done or not done will have to be re-evaluated based on the conditions prevailing at the time the item is picked up again for implementation.

So in some cases the work partially done towards an item may be irrelevant when you take up the item again after several weeks.

The very fact that you mention that a backlog of blocked tasks exists is a clear indication that many Sprints are not meeting their goals and this calls for a serious review of the whole Scrum team's methods and this includes the Product Owner.


02:43 pm October 23, 2019

Were currently having this debate in my organization. I think the additional complexity is added because were using Azure Dev Ops which doesn’t natively support Hold or Blocked as a state. In my opinion Hold and Blocked are both states that mean the item is temporarily not being worked for one reason or another. The only time the distinction matters between the two is when you plan on reporting on one or both of the items or if you plan on taking some actions on one set that you wouldn’t take on the other.

For the purposes of the teams I work with… We don’t bother splitting hairs between Blocked and Hold. We simply choose one or the other state and provide description for placing the item in this temporary state. Sometimes it’s a big reason that will remain for months. Sometimes it’s a small reason that will remain for only days or weeks. Since every item can be different we treat them independently upon review or grooming sessions. For example if we see an item in the Temporary State (Blocked or Hold) we assess the items conditions and make a follow up decision on each. Some examples of follow up decisions would be setting a reminder to follow up later, removing the item as it’s no longer needed, or relating the item to a traceable dependency.


06:49 pm September 21, 2022

Great answers, but question ... Whenever we've used blockers, we've found it to be an emotionally loaded word.

Invariably there is always a person at the end of a blocker and no-one wants to be "accused" of being a blocker. I've found this erodes psychological safety even in well functioning teams.

Do you have any suggestions for phrasing blockers differently ?


08:28 pm September 21, 2022

Impediments.  

Honestly, if someone is preventing others from being able to complete work, it should be called out.  I realize that being politically correct is important, but truth be told someone is being "blocked" from completing work.  There really isn't a polite way to state it that isn't obvious.  I can get creative though. 

 

  • Lego (wait for it to sink in)
  • Jammed
  • 3d Rectangular object
  • Obstructed
  • Waiting
  • Unable to progress
  • Barricaded

08:59 pm September 21, 2022

Invariably there is always a person at the end of a blocker and no-one wants to be "accused" of being a blocker. I've found this erodes psychological safety even in well functioning teams.

Would psychological safety be improved by eroding the transparency you describe?


07:10 am September 22, 2022

Thanks Daniel, yes you're right, lets call a spoon a spoon :) I just find the word "blocker" so final and I have often seen people react to it more strongly than they should.

I am talking about external blockers as described by Ian. In a well functioning team, issues that might turn into external blockers, impediments or dependencies are identified and planned in during backlog refinement. So blockers in these cases are discovered during the sprint, in which case they may not align with the priorities and workload of the person or team who can unblock them. 

I do like "waiting" but also agree with Ian that we don't want to erode transparency. I'm not sure what the right answer is, so perhaps I should leave the terminology alone for now.

 

 


11:14 am September 22, 2022


I am talking about external blockers as described by Ian.

This is an ancient thread, but looking back with hindsight after 9 years I'd say the missing piece is commitment.

The internal vs external lens remains useful. However, I would be less concerned about that now, and more concerned about nurturing an awareness of the commitment being made by Developers, and of the need to demonstrate accountability regardless of where an impediment might subsequently come from.

In a well functioning team, issues that might turn into external blockers, impediments or dependencies are identified and planned in during backlog refinement.

I'd suggest that Product Backlog refinement ought to ensure that this does not happen.

Refinement is the activity of making work Ready for Sprint Planning, meaning that the Developers are confident it can be Done in a Sprint.

So blockers in these cases are discovered during the sprint

 

That's often a problem, and it indicates that the work has not been satisfactorily refined in advance.

Refinement can be seen as the art and science of de-risking a Sprint. When a team goes into Sprint Planning, the question should never be "can we do this work?", but rather "should we do this work in order to meet a useful Sprint Goal?"


01:56 pm September 22, 2022

Thanks for clarifying Ian.


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.