Blockers vs. On-hold?
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!
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.