An impossible Story size dilema
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?
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.
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?
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?
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?
> 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.
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.