Blockers vs. On-hold?

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.

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

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.

>>>>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.

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.

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 ?

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

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?

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.

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?"

Thanks for clarifying Ian.