How to break a user story that changes something huge internally e.g. underlying data access layer [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

We have a few products with one of the product use flat files for persistence.. Other products in the suite can use that data (via API) but only one at a time..

We cannot put the whole开发者_如何学运维 files in DB as its huge data.. 20GB+.. but still we have found a solution where some data can be put in DB.. e.g. user interpretations, meta info, markups etc..

So the story is like:

"As a user i can concurrently access product A data from product B, C and D". That is huge i.e. approx 6-8 months

Even if I keep it as "As a user i can concurrently access product A data from product B". It’s still huge.. i.e. approx 5-6 months

Even doing like following, It’s still huge.. "As a user i can concurrently access feature X of product A data from product B". i.e. approx 4-5 months.

The problem is if we can do one thing (one feature, one product) we can quickly do all..

how can i break this story into sub-stories.. or should i accept that some stories cannot be further broken into sub-stories that can fit in one iteration.

PS: we use scrum

---

Ask yourself (and your team): What makes the story so big? Is there absolutely no benefit that can be shown along the way? Features and products would be the obvious cut, but might not necessarily (as you've shown) be good enough.

How about sub-components of the feature? What are you putting in? Is any of it externally visible or valuable?

Do you have authentication, configuration, or other "standard" aspects of the product? You could cut those out and put them as user stories.

Perhaps the 3-5 month features can be cut down further?

Anyway,

I hope this helps,
Assaf.

---

What you are describing is what we call an "epic" - it's really a collection of smaller stories that you are describing with a much larger descriptor. I suggest you do some more analysis to determine what parts of the system will be impacted by your request. You might have groupings like Reports, Entry Forms, etc that are individually impacted by the request.

Tackle the impact of the "epic" request on each area as a user story. For example, "Enhance Report X to include data from Product B", "Enhance Report X to include data from Product C", etc. I don't know enough about what you are changing to make the titles more descriptive but hopefully you get the idea. Keep at this deconstruction until the stories get down to the sweet spot of 2, 3, or 5 points each.

The nice thing about this is that it also will allow the PO to make a decision once they see all of the costs for this request. They may decide that we really only need access to data from Product B alone to be successful once they see the costs to include Product C also.

---

Agile fully supports that some features have a longer horizons than a typical sprint period (2-4 weeks). Certainly the story can be broken down into tasks. In this case, I recommend prioritizing the tasks for this story and burning them down using your scrum methodology. At the end of each sprint, you should still have 'working software' that you can demonstrate / test. You may not have the full feature yet, and that is okay.