This is one of the definitions that I asw for user stories -

When the time has come for creating user stories, one of the developers (or the product owner in Scrum) gets together with a customer representative. The customer is responsible for formulating the user stories. The developer may use a series of questions to get the customer going, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process.

In a large organization there could be multiple lines of business. For a particular line of business , there could be multiple applications (more than 10) that may be involved in fulfilling a business requirement. The requirement to each of these application teams could be provided by a business analyst and the high level solution could be formulated by a solution designer.

In scenarios such as these , would a single user story be defined for a specific change request that impacts multiple applications or would different user stories be created for each application? If it is a single user story then would a separate SRS be defined for each impacted application would it need to be associated with the user story defined?

  • Can you give us an example what you mean with "involving multible applications"?
    – k3b
    Commented Feb 11, 2013 at 7:55
  • For instance when a user places an order to purchase a mobile phone service in AT&T or Verizon , there could be a number of applications involved in fulfilling the order. A CRM system to capture the order , an order management system that orchestrates the order , number of webservices each providing a unique capability (credit check / shipping etc) that could be consumed by the order management application , provisioning / activation application and billing application . So a specific change could impact all these applications. Commented Feb 11, 2013 at 16:39

1 Answer 1


The effect on contributing systems is irrelevant at the level of a user story. The user does not care how it works.

As a [user role], I want [something] so that [benefit]

Ex: As a [mobile phone customer], I want [buy a phone] so that [I can make phone calls].

Note the total absence of any mention for the need to build cell towers ;)

  • Is it not correct to define a user story for a each constituent system. We use rally to define and track the progress of each user story.If a user story is defined as something common for program , then it might be difficult for the individual teams to track the progress. So can a user story be defined at an application level? Commented Feb 12, 2013 at 15:05
  • @PunterVicky: I'm not sure I understand the question. If you asking can a high-level user story whose implementation spans multiple application systems be broken down into subordinate stories for each subsystem, I say yes. If you're asking can a user story be used to define some common application functionality, such as a library function, I'd say both yes and no. Yes, if you really want to, but no, it should not be necessary; implementing the library function would be a task subordinate to an existing Story. In general, track only what is necessary. Commented Feb 13, 2013 at 17:25
  • Thx Steve.I though story when created for component systems would be same as the high-level user story as the user story is something that defines what a specific role wants would not vary based on the constituent applications.When I said track the progress this what I meant - Each user story could have multiple system requirements. Each system requirement might be fulfilled by an application that is part of the overall project.Each component application would have a dev & qa team and managers of these teams might want to track if a user story is developed / tested in the release successfully. Commented Feb 13, 2013 at 17:43

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.