Overlapping user stories

Hi Nicklas

You say that the user stories overlap. By definition user stories must be independent (as per INVEST criteria), so the question is, are your stories properly formed?

It's quite possible to have well-formed, independent user stories that overlap at a task level. In other words, one user story ends up partly done by implementing another. In this situation the team can order its sprint backlog and base the estimates accordingly.

Note too that estimates should be revised and updated by the team *throughout* the sprint. Is your team doing that?

Also, you might want to raise defects as tasks *against* stories instead of making them stories themselves. This will reduce the overlaps at story level.

No, the stories are most certainly not well formed. But I find it interesting to read your post about stories that do overlap at a task level, because in essence that is the case for us. And I fail to see how to properly communicate to the product owner that they each take 10 hours to complete, but if we do both it takes less than the sum of them. Well, it's easy if we're just talking about 2 issues, but when we have 100 issues, and perhaps 20-30 overlap in several ways...

The defects tend to address stories that were part of previous releases of our product, and as such, there are no proper current stories to raise them against. I don't really know how to work with that (might be a noob thing... :-) ), so we tend to keep stories as stories and defects as defects.

We are updating estimates, yes; but the problem occurs far earlier than that - it's about figuring out how much to include in a sprint, and how to help the product owner understand the ROI for different issues - it's hard when the issues are not independent.

Hi Nicklas,

Is it not obvious during sprint planning that stories overlap?
Why don't you want to rewrite stories?
Do all team members understand the stories after sprint planning?

/Fredrik

Posted By Nicklas Kittelmann on 04 Mar 2013 01:43 PM
We have an issue tracker into which colleagues can enter bugs and feature requests. However, what tends to happen is that the bugs and feature requests overlap, that is, they describe partly the same thing. And then it gets kind of tricky to know how much to include in the upcoming sprint. Sure, we time estimate the issues, but 10+10 sometimes equal 20, and sometimes it equals 12.

Do you have any recommendation? We would prefer not to rewrite the issues, but it is not easy to get a proper amount of issues in a sprint, not to mention our velocity that can be way too high sometimes (just because we fix 4-5 issues that essentially are the same).

I don't think you're going to be able to do this without rewriting the stories. It's a drag, but there's no simple estimating method that I know of that allows you to account for the overlap.

Yeah, I think you're all correct. I will need to re-write the stories. Take my defects and write proper stories that can contain one or more defects, and then when we time estimate what to do in a sprint, we time estimate the stories and not the defects.
Thanks for all your help.

My 2 cents ...

Bugs and features should be taken separately if not bugs are constructive and could be part of some feature as per Product Owner's opinion. Moreover as mentioned in one of the replies, features should be INVEST type, so it should not be overlapped. In that case, we need to properly formulate to bring the independence.