Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

An impossible Story size dilema

Last post 12:57 pm September 15, 2014 by Andrew Forkes
6 replies
08:02 am September 11, 2014

I have a dilemma that I'd really like some lateral thinking help on...

We have a story in our Backlog that has been estimated at a size bigger than the sprint duration.

"Aha!", I hear you say, "Easy - that'll be an Epic then ... break it down"

Yep, I'd agree, except it seems you can't. The implementation solution has a number-crunching task that will take 15 days. No amount of parallel processing can change this and obtaining bigger machines would be unfeasible financially. Yet the value of the Story is in the end result of that 15 day processing compute.

So what to do?

The Story won't fit in a single Sprint, yet contains real customer value. Splitting the Story artificially into 2 parts doesn't work, as the compute could fail at any point, meaning a re-run would be needed (thus shouldn't attract Story Points for part completing i.e. Part 1, but not Part 2).

I've never encountered a Story like it.

Any ideas?

09:00 am September 11, 2014

How long is your sprint? Is it already at the max of one month, or can you increase the duration?
Can you reformulate the story in a way, that the data processing of 15 days is started, but the result is not part of the acceptance criteria?
I think a task which mainly uses a machine for 15 days but not the team does not have to be integrated in the sprint.

05:50 am September 12, 2014

Thinking more of this issue I've been guided by what the customer value actually is..

It occurs to me that there is value in being closer to the goal in the same way that if I have 3 hours to wait until lunch there is value in waiting an hour (and thereby reducing the time to until lunch to 2 hours); My stomach might not be full, but 2 hours to wait is better than 3.

So perhaps the key here to solving this type of Story is in understanding that whilst the customer won't be entirely fulfilled, they will be closer to achieving the 'value' they desire.

Any other takes on this?

11:34 am September 12, 2014

If the 15 days is just computer processing time, I would definitely say to just create the ticket to start the process. Acceptance criteria being that the process is started, and perhaps kept running during the Sprint.

This way, you can tick it off as done just before Sprint review.

Out of interest, if it failed after 10 days for example, would you have to restart from the start?

12:56 pm September 14, 2014

Hi Chris,

Good suggestion, I had thought of that type of approach but it's not just as simple as starting a standalone process. It need baby-sitting continually, and that requires resource, and so costs time - which should ideally be equalled by a reciprocal return in value to the customer :-/

Your comment:

> Out of interest, if it failed after 10 days for example, would you have to restart from the start?

Unfortunately yes, and at any point in between (!)

Vexing huh?

01:37 pm September 14, 2014

> Splitting the Story artificially into 2 parts doesn't work, as the compute could fail at any point

That isn't really a consideration as long as there is value in starting the process and value in finishing it. The issue lies in how that value becomes invested into the increment.

From what you say, it seems likely that just kicking the process off will not actually increase the value of the product by the end of the Sprint. If the implementation of the processing task was reusable then it could supply intrinsic value. From what you describe though, it is only the end result that matters.

> It occurs to me that there is value in being closer to the goal...

No, because the only value in agile practice lies in what is actually delivered. There is no partial credit based on how "close" you believe you are to delivering that value.

What you seem to need is the data from the process, and not the process vested into the product. If this data helps to inform the Product Owner about the future shape of the product then it could be seen as a backlog refinement activity.

12:57 pm September 15, 2014

Yes, the end data represents the value, the process not so (even intrinsically or reusably).

In much the same way as there's no value (to a customer) in how you achieve something, this edge case raises some interesting points about how agile practises such as Scrum can handle such Stories.

The manifesto states 'Individuals and interactions over processes and tools', and I personally always like to work from those left-hand sided views. This particular problem though maybe more easily solved by simply 'changing the process' to accommodate it. Splitting it into Start and Finish Stories may not be ideal, but the computation-process is largely outside the control of the team, and should not intentionally be linked to (as a roadblock) if we are to avoid interdependence.

An edge case perhaps, but certainly an interesting one that really prises open some agile practises.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.