What to do with user stories that depend on horizontal integrations?

Question

How do you handle a user story when it depends on horizontal integrations in an application?

An example would be a user story such as, "I would like to have audio help on the start screen." Let's say that audio help depends on us creating an audio player in our application which would handle audio across multiple screens and may even be a component of another user story such as "I would like to have audio help on the settings screen". I guess what I'm getting at is how to handle architecture in user stories?

What I have considered so far:

1. have common repeated task in each story
2. break out architectural and horizontal pieces into their own stories
3. just plain don't write
   stories for these issues and instead track them independently

Answer 1

A user story is actually some text of your customer. You should split that story into valuable backlogs. If it's hard for you to write them, because they take too much time to be reasonable valued you have to consider a story split. That means you talk to your stakeholder and recompose the user story in more smaller user stories.

The thing is, that scrum is how you use it in your company. The workflow is nearly the same, but there will be many companies which say that a 2 week user story divided into ten 1-day backlogs is okay and other companies say one user story max. 2 days and one backlog not more than 1 day is okay.

In your case, if your user story depends on a component which does not exist yet, you also have to define that component first, don't you? So you have your other user story.

Answer 2

What you have sounds like what is known as an Epic. This is basically a user story that is too large to be implemented, tested and accepted in a single sprint. This should typically be the starting point to go back to the customer and try to derive more details and specifics around what they want. You should be doing this as a regular part of your backlog grooming, identify stories that are too large or too broad and figure out how they can be split into smaller chunks.