TL;DR
A blocked item is supposed to be inspected and addressed; it’s not intended to be a perpetually immovable stumbling block. If you decompose your story into effort-based tasks, the “negotiable” element of INVEST criteria allows you to swap small dependencies in and out of your flow to make room for more actionable work-in-progress (WIP).
Breaking Up Time-Dependent Stories Into Effort-Driven Tasks
As the external factors can only make practical progress on the story every few days the story is stuck in the Development column somewhat.
In Scrum, the estimation is based on level of effort, not time. There are a number of other questions and answers on this topic, so I won’t belabor it except to say that long-running tasks aren’t inherently high-effort tasks.
Scrum is based on time boxing, so dragging a single story from Sprint to Sprint is always a framework anti-pattern. There are certainly cases where an effort started in one iteration won’t pay off until a future iteration, but that doesn’t remove the obligation to time box your stories or limit work-in-progress.
As a pragmatic approach, consider breaking your user story up into stories or tasks that treat kicking off a process as distinct from collecting the results or iterating on the work item. While vertical slices are a general agile goal, in Scrum time boxing tends to yield more consistent results because of queue theory: smaller batch sizes, WIP limits, and shorter queues are simply more efficient.
As an example, rather than a “story” like:
Embiggen the whatchamacallit over 4 Sprints.
consider breaking down the parent story into Sprint Backlog stories like:
# Kick-Off Story
As a team member,
I want to launch the embiggening script as a background job
so that it can continue to run until completion.
# Follow-Up Story
As a team member,
I want to check the embiggening log periodically
so that I know when the script is done.
# Collection Story
As a team member,
I want to capture the results of the embiggening script
so that it is available for other stories that have embiggening data as a dependency.
In this example, each story likely has a very low level of effort. Kicking off a script, looking at a log file, or gathering up completed results are all small tasks or chores that are probably 0 or 1/2 point in size, individually or collectively. This means that, while the stories/tasks have a linear dependency (e.g. you can’t inspect or use the data before it’s gathered), each backlog item can fit within a single iteration. Furthermore, because it’s not sitting in the “in-progress” state indefinitely, you avoid abusing your WIP limits.
Swapping and Reordering Backlog Items
In many cases, such stories/tasks can sit in your Sprint or Kanban “Ready” queue until someone hauls them out. They can then be handled quickly and either moved to “Done” or returned a little lower down in the “Ready” column to make room for other active tasks in the Sprint. As long as your current Sprint Goal is not jeopardized by moving a task back to “Ready,” or by leaving it undone altogether, this is a perfectly legitimate approach. The results of your task chain aren’t actually needed until your Sprint Goal depends on them!
Neither Kanban nor Scrum prevents a work item from being removed from in-progress swim lanes. While the Product Backlog is ordered, a Sprint Backlog or Kanban board more accurately represents a coherent process flow, not a strict FIFO queue. So, while the rule is that you shouldn’t exceed your WIP limit, there’s nothing preventing you from modifying your WIP limits or removing items from the flow rather than simply blocking indefinitely. A blocked item is supposed to be addressed; it’s not intended to be a perpetually immovable stumbling block throughout the Sprint or across the project’s lifecycle.
