2

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. – Robert Harvey Feb 12 '15 at 1:18
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.

| improve this answer | |
  • +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 '15 at 1:06
1

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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