1

TL;DR: Genuinely long running story drags from sprint to sprint. What to do?

We have a story which is taking a long time to complete because of the various external factors involved.

Each sprint does gain some progress on the story but it is clear that it will not get far in a reasonably short period of time.

The point estimate on the story is average for our team and the story is not blocked.

As the external factors can only make practical progress on the story every few days the story is stuck in the Development column somewhat.

What should be done with this story?

I have considered converting the work into a RAID item. I am not sure that this is appropriate. Assume that it is not.

For those interested...

The story is genuinely taking a long time because it involves code being developed for an environment in a far-off country. The required process to dev-test the code involves a round-the-house trip through multiple time zones and slow-to-respond resources. Very much a human thing, but also impacted by needing some evidence gathering of values which take days to collect. (Like if the task were physically measuring continental drift.)

  • Why the down vote? How can I improve the question? – Matt W Jan 25 '18 at 15:35
  • Yes, I am aware that this is one of those annoying questions. I am hoping that those reading it will try to avoid defaulting to attempting to re-frame the question, the situation or arguing that "this shouldn't happen". – Matt W Jan 25 '18 at 15:41
  • 1
    While I didn't downvote, I suspect the downvote is because you're implementing an anti-pattern without justifying it or explaining how you tried to fix it (and why that didn't work for you). "I know I'm doing the wrong thing, and plan to keep doing it! How can I make it hurt less?" is usually a downvote magnet. – Todd A. Jacobs Jan 26 '18 at 11:55
  • 1
    I guess there's no point doing it now just to get that point back... I'm not saying I want to stick to the anti-pattern, just that I can't figure a better approach than breaking it up in such a way as to lose single-story focus on a single practical task.I accept your reasoning, of course. – Matt W Jan 26 '18 at 14:39
  • Questions can always be cleaned up and improved, provided they don’t invalidate the original question or its answers. This not only helps future visitors find good long-tail questions that apply to them, but question edits also allow previously locked-in legacy votes to be changed to reflect your improvements! – Todd A. Jacobs Jan 26 '18 at 14:50
4

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.

2

because of the various external factors

is the cause. That's what needs to be treated.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

The Scrum Guide

Context is king, so without knowing specific details, a quick idea (with a reference that I can think of at the moment) is Slicing to isolate the external dependencies that cannot be entirely removed.

  • What if it were simply that the development task is to run a script which collects information and that the script takes longer to run than the sprint? – Matt W Jan 25 '18 at 16:02
  • 1
    Once again context is king. Why is that information valuable? Can it be separated into multiple scripts to retrieve higher value information first? Does it make sense to change the length of the iteration? Is the wrong approach being used to plan, execute, and evaluate the effort? – Alan Larimer Jan 25 '18 at 16:13
-1

Traditionally the team carries the story through the sprints until it meets your Definition of Done (whether that's release to live, passes acceptance tests, whatever). Don't try to assign some of the points to one sprint and some of another, keep it simple and make sure that when it's done all the points are added to that iteration.

The reason this works from a velocity point of view is because velocity is based on the average velocity of a number of sprints. Your achievements in the preceding sprints will look unimpressive but when you assign the points to the sprint in which the story was completed in, the average will ensure the numbers work themselves out.

I am extremely dubious that this story can't be split down, in my experience most stories can be split into components which are 5 days' or less.

Ideally the team should complete everything they agree to in the sprint planning.

Some things to consider when looking at why this story is taking so many sprints to complete?

  • Is the team pulling in too much work?
  • Is there too much unplanned work coming in?
  • Is the story too big and needs to be split down?
  • Is the story unimportant (and everyone knows it and therefore is quietly ignoring it) and should actually be abandoned?

However, if as you say it genuinely is impossible then don't worry too much about it and simply claim the points when it is done.

TLDR

The numbers should work themselves out, put your effort into working out why why the story isn't being completed.

  • The task is very important, cannot be sped up and cannot be broken down. It's not the complexity of the task but simply the time it takes to physically do the work. Added a bit of an explanation in the post. – Matt W Jan 25 '18 at 15:34
  • @MattW I've tried to add some more details to my answer. If you can let me know specifically what you're worried about (I assume it's sprint velocity calculations) I may be able to refine further. – Liath Jan 25 '18 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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