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
  • 2
    User stories do not address architecture, integration, hardware or any other infrastructure concerns. Those things are implementation details. Feb 12, 2015 at 1:18

2 Answers 2


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.

  • +1 for a good answer, however I would like to note that the OP never actually mentioned he was using Scrum.
    – maple_shaft
    Feb 12, 2015 at 1:06

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.