There's something that has always bothered me with Scrum. Hopefully I can get some insight here.
With Scrum, we try to break the backlog down in vertical slices. Let's say stories A and B. These stories are supposed to be customer oriented and deliver value. Assume here that they have similar customer value.
Now, let's say that, to implement, A and B both need a shared infrastructure. So let's say we're at backlog refinement. If I ask the dev team to estimate in story points, they might estimate them each at 8 points, if they are estimated separately: A8, B8. This is good for me as PO because I can move the stories around in the backlog without breaking anything.
However, when forecasting, my backlog will appear heavier, because, if combined, they might be delivered with a lesser effort than the sum of the parts. If my team has a hypothetical velocity of 13, it will look like they won't be able to deliver in 1 sprint. If there are many items like this, it will be impossible to have any visibility of a timeline beyond the planned sprint.
If we have multiple stories with a same shared infrastructure, the backlog will seem very heavy, and forecast will be impossible.
I have seen 2 variants:
Split the infra work to a separate "technical" story: A3, B3, T5 This solves the estimation process, but it's a horizontal slice. The infra itself has no customer value. Also, the backlog now contains dependencies, because the stories are no longer atomic, which means that I can't reorder them without being aware of the dependencies. Without looking at the specifics, I would have chosen A and B to be done first, because they are low effort and high value. So it's going back to classic project planning.
Estimate the infra effort in one of the stories only, and estimate the second one as if the first one is already done: A8, B3. The downside here is that one story will seem more complex than the other, so if I don't look at the details, I will be inclined to prioritize story B, because it will have the same customer value as A, with less effort.
So the questions are:
- Are there any documented ways to handle these?
- Have you found ways to deal with situations like this that don't require you to pick between the downsides mentioned here?
I have dealt with these a bit with an ad-hoc way, by using one of the two options above and by marking dependencies, so that I don't put prerequisite tasks before subsequent ones. If I do, I redistribute the story points. But it looks bad for anyone else looking at the backlog, and I prefer the backlog to be a useful and transparent artifact.