4

In Agile software development, when is a story or task considered blocked? Does the task need to be in progress? Or is the fact that a dependency is not completed, enough, for a task to be considered blocked?

For example, the UI team needs an API from the backend in order to complete a task. If the UI team can work on some of the UI before needing access to the API, would the UI team wait until the point at which they need the API to mark the task as blocked? Or would they mark it blocked immediately?

At which point is it more useful for project tracking to mark the task as blocked?

7
  • 1
    What is preventing you from deciding that with your team?
    – jonrsharpe
    Nov 20, 2021 at 12:45
  • 1
    How are you marking tasks as blocked?
    – Helena
    Nov 20, 2021 at 13:00
  • Thanks for the comments. I was mostly curious if there’s a time that marking a task as blocked is most useful. The engineering team may be communicating about dependencies but not all the stakeholders may be familiar with the details of every task. So was curious about marking tasks as blocked at certain time might be helpful for people without detailed knowledge of a task.
    – Sandro
    Nov 20, 2021 at 15:27
  • 1
    @Sandro It is in fact tagged well. In traditional project management, there's the technique of fast tracking that allows to circumvent as much as possible dependencies that could block the schedule, and advance (if necessary at risk of re-work). But in agile fast-tracking is built-in: tasks are defined just-in-time, are more granular, and there's the opportunity to put one thing on hold without blocking the whole thing. It's rare that full UI is on hold because of a missing API; & API isn't delivered in one piece. You always...
    – Christophe
    Nov 20, 2021 at 22:21
  • 1
    ... have to find what is really blocking, and what does not really have the same dependency.
    – Christophe
    Nov 20, 2021 at 22:24

4 Answers 4

9

A key principle of Agile Software Development is trusting the team to get the job done. Part of that is letting the team define what it means for their work to be blocked and what to do about it.

Generally speaking, if there are dependencies or impediments to progress, those should be identified as early as possible. In this specific example, the UI team should have made it clear that work from the API team would be necessary to complete the work. As a self-organizing and self-managing team, the UI team would be able to make decisions about when to start the work based on conversations, forecasts, or commitments with the API team. If the UI team did decide to start the work, the next step would be to make sure that the API team was aware that work was starting and attempt to determine when the API would be available. If the UI work was as done as possible without the API, this should come up as soon as that happens. Clear communication about the state of the work every step of the way.

However, there's also another solution. Dependencies should be eliminated. Instead of having a UI team and an API team, put people who can develop both the UI and the API on a single team so that way they can work together without having a dependency across team boundaries. The people with the right skills can pair up or mob up and deliver the work.

3
  • Thank you! You make a great point about removing blockers altogether. I marked this as a project management question thinking about blockers in terms of visibility in the project management software, but this is ultimately a communication issue and not an agile project management issue. Like you and others said it’s important to call out dependencies and impediments as soon as the task is created. Marking the task as blocked shouldn’t be a surprise to anyone.
    – Sandro
    Nov 20, 2021 at 15:19
  • Thanks everyone for taking some time to answer this question! I think this answers my question and the answer is clear communication. The way I plan to think of it is, the project tracking software is for tracking not communicating issues. Meaning the team should communicate blockers and then track them in the software.
    – Sandro
    Nov 20, 2021 at 15:36
  • 1
    @Sandro A communication issue is a project management issue. Communication and coordination are key aspects of project management, whether you're using agile, traditional, or hybrid approaches. The next step is to figure out how to communicate.
    – Thomas Owens
    Nov 20, 2021 at 15:37
3

Agile Software Development is a very broad term and there are as many opinions about how to best proceed as there are method gurus around.

But there are also hard facts of life, i.e. that some tasks cannot be completed even with the best will, whatever the method, and sometimes due to unexpected situations. So let's go back to the roots of the agile manifesto principles:

#1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
#4: Business people and developers must work together daily throughout the project
#7: Working software is the primary measure of progress

With these principles in mind, there are four obvious kind of reasons that may block any task in any method (examples in scrum context, but agile is not necessarily scrum):

  • Dependency on people: one of the stakeholder is not available. In times of pandemics this is an acute risk. But in normal time it might also happen: you start a sprint and all of the sudden, the business user with whom you need to have a conversation about a story is ill. Ouch.

  • Dependency on knowledge: the knowledge needed to perform the task is not available. This can be unplanned: you finally have this user conversation about the story, but oops... the user has some doubts and need to verify the business rules. And does not come back (early enough).

  • Dependency on code: maybe you're depend on another code that is part of the same sprint, but which gets delayed because of one of the previous cases? You could of course use a mock to circumvent the issue, but will it be workable software that delivers value?

  • Dependency on time: maybe it appears that the task is not really blocked, but it'd be obvious that it could only be completed after the agreed iteration end.

In all these cases, whatever you try, you might not deliver the working software with the value it should. It'll be safer to block the task, WELCOME CHANGES, and work on something else that may deliver at least as much value.

If the blocking dependencies are resolved, you may resume your work on the task, unless there is the time dependency that might require to postpone it to the next iteration, eventually breaking down the task in simpler parts.

2

Before a task enters a current sprint there is no need to mark it as “blocked”. You can, if you like, but you don’t have to.

But maybe the blocking task is not seen as having any urgency because nobody realises what it is blocking. So to give it some urgency, you can mark both as blocking/blocked, so the blocking task is more likely being put into a sprint.

1

I dont think there is an official designation, but "Blockers" normally refer to unexpected problems which prevent you completing the task. Usually its a reliance on something outside of the team. "We are blocked on this task because we need v2 of the dependency and it hasn't launched on time."

As opposed to a dependency, which might just be some other task you have to do first and is completely within your control. Or an expected delay, "we cant do this task because it needs v2 of the dependency which will be launched next week and not delay our project"

1
  • The team may be 100% aware that task A must be finished before task B is started. And even if the blocking is external, there are blocks that don’t get unblocked unless your team puts fire under someone’s backside, so that would be a task for your team as well.
    – gnasher729
    Nov 20, 2021 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.