Marking tasks as 'blocked'

Hi Melanie,
what does your Scrum Master say about this? Technically you are talking about impediments, and the Scrum Master is responsible for removing them. If they do not endanger the sprint goal, they might be of lower priority, but still your Scrum Master should help you to optimize the flow and eliminate waste which emerges when you wait for someone else.
Is this someone on your team or external?
Best, Ludwig

Did the story meet your requirements in the definition of ready - was it testable?

Use the INVEST model for your DofR

Independent
Negotiable
Valuable
Estimatable
Scalable
Testable

I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimatable You must always be able to estimate the size of a user story.
S Scalable (small sized) User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible.

I am the scrum master (PM moving into scrum). The tasks are blocked because they are dependent upon some copy that needs to be written by our HO Marketing, who I am nagging!
Stephen - I understand the whole user story thing, I was asking about individual tasks that could potentially block completion of a story but at the moment aren't....

What's a DofR?

Hello,

" marking a task as blocked " but " it isn't blocking the sprint goal "
Does it make sense?

and what is the value, importance of a task blocking the sprint goal ? Apocalyptic ? :-P

Regards,

Max

Definition of Ready. More or less equals to "my user story is INVEST"

Hi Maxime, yes - I think my post makes perfect sense! All I'm asking is people's opinions on marking a task as blocked if it isn't yet stopping the goal from being achieved in the timebox...
is it just me or do people not understand what I'm asking?!
I think it's a personal thing Personally, I like to move tasks that are dependent on something else into blocked if that something else is taking too long... it is a quick, bold visual way of seeing that someone needs to pull their finger out!
Thanks for all your thoughts.
Mel

If the impediment is internal to the team, then this implies that resolution lies within the remit of the team. Having a signal on a Scrum Board may not therefore be necessary. However, I generally coach teams with physical boards to turn items upside-down to signal internal impediment. The action may be to swarm.

External impediments require action to be taken by parties who are not team members. These are blockers that require clear signalling to external stakeholders. I often coach teams to slap day-glo sticky notes on external impediments.

The Scrum Master should facilitate the removal of either type of impediment, including any negotiations with third parties. Note that external impediments imply that the team is not in control of its own process and is unable to take all items to completion as per the DoD.

Thanks Ian, that is really useful. Unfortunately this particular impediment is someone who is part of the team but who has commitments elsewhere. Our company is unable to provide team members 100% for full sprints, we're trying to work around this..!

> Unfortunately this particular impediment is
> someone who is part of the team but who has
> commitments elsewhere. 

Unless those commitments were made by the team (which is unlikely) then this must be viewed as an impediment that is external to the team. When I encounter this situation as a Scrum Master I do 3 things:

1) Try to mitigate the impediment by negotiating the team member's availability
2) Inform the PO of the associated risk to delivery, and work with the PO to explain these risks to stakeholders and influencers
3) Gather metrics about the impact of non-availability during the Sprint, so observations can be evidenced.

Hello Melanie,

Sorry I better understand your problem. When I wrote my first post, I only had the first post of this thread.

"The tasks are blocked because they are dependent upon some copy that needs to be written by our HO Marketing, who I am nagging" => I think your should have a PO in your team?

isn't it?

Hi Melanie,

looking at the example you give: "The tasks are blocked because they are dependent upon some copy that needs to be written by our HO Marketing, who I am nagging", I would keep the tasks blocked if the HO marketing did not commit to delivering the copy in advance, and move the tasks back to the todo column if the HO marketing did commit. The blocked tasks could lead you to multiple impediments, eg.
- We are not refining our product backlog items, so that external dependencies are resolved before we pull them into the Sprint
- We do not have the necessary skills in our team to deliver done product (copywriting)
- etc etc

The trick is to identify the impediment that, once resolved, will lead to permanent improvement. This is hard!

Regards, Paul

Definition of Ready (DofR)

then this becomes an impediment that the Scrum Master needs to remove, but if this does not get resolved then it will highlight where the bottle necks are in the project

hi Melanie

With regards to " I like to move tasks that are dependent on something else into blocked if that something else is taking too long.."

I believe that the Scrum master should not be doing this activity, and should be down to the PO and The Dev Team. One of things I have come across in my personal experiences is new Scrum Masters who were formally Project Managers, falling back into there old mind set as a PM and not as a Scrum Master.

Contrary to popular belief, the Scrum Master and project manager roles are highly different and shouldn't be confused.
Traditionally, the project manager is a leader, a decision maker, a planner, someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. The Scrum Master's role is more that of coach and facilitator, a role that sits between the project and the customer. The Scrum Master doesn't manage the team that produces the work; instead, he supports the product owner, coaches the team, and makes sure that Scrum processes are adhered to. The Scrum Master is responsible for the Scrum process, its correct and continuous implementation, and the maximization of its benefits.

Hello,

In other words the role of the PO should be to take versatile needs from HO marketing and fix it in stone. Even if the needs are not so right...
Trying to make a bulls-eye for every feature is just impossible at the beginning. Every person involved has to take its own marks.

For avoiding your problem, you should perhaps tell to the HO marketing to make smaller documents (isn't it?) with the PO. Just for understanding the need. And try to implement this need as a proof of concept. By doing several iterations on this need (better poc and small document for improving the current poc for a better poc) inside or not a Sprint, in parallel or not with other features, you should perhaps see the greatest emerge?

Regards,

Maxime

Hi Melanie,

Marking a task as blocked is to enable one of the fundamental goal of scrum "transparency". People outside of the scrum team are viewing the scrum artificats - sprint backlog, sprint burndown etc. and it helps for them to have a pulse on how the team is doing. Blocked helps anyone understand where the current task is. Normally once a developer takes a task it is supposed to be completed within a reasonable time (for our team with 2 weeks sprints, we have laid down a max of two days as a reasonable time for a granular task). Blocked just tells the team members that he needs help from either someone within the team (e.g. code review to be done) or from someone outside of the team. These blocked tasks are discussed in daily scrum and people swarm to help out. So even though the sprint goal is not blocked, there is still value in flagging the tasks as blocked.

Regards,
Dharmesh

Hi Melanie,
Just my "50 cents" here but normally a task should be "marked" blocked if it was initially started , but became blocked along the way. If the task has not started yet, normally you can mark it as an item with a dependency - maybe with a brief description of it also - so everybody can keep track. What happens next, depends also on the estimated effort for this task, meaning if you're on day 10 of a 15 day time-box, and based on previous metrics - average velocity etc - you know that this task will take approx. 3 days to complete, you have to do something asap to remove the impediment otherwise you risk the sprint goal.