I'm in a situation where we strive in different directions on how we should use user stories.

As an example we have a Salesforce (and the user) requesting a document to be created, sent and archived and so on.

The workflow is like this: SF -> Gateway 1 -> Gateway 2 -> DocGen

The work is done by four different teams, depending on each others work and each team need 2-8 days of work. A guess would be an average of 16 work days.

The question then. One group want it to be one big user story with sub-tasks as it looks cleaner and it's only one "true" AS A User I want to... My objections is that it will never be possible to finalize the US in one or even two sprints.

I prefer to see it as three stories roughly like:

  • Request document X to be sent from Salesforce
    • Collect field to include in JSON
    • Send request to Gateway
    • Handle HTTP return codes
  • Handle request for document in Gateway
    • Handle for Gateway 1
    • Handle for Gateway 2
    • Send to Docgen
  • Create document X from Salesforce request
    • Handle request
    • Create document
    • ...

This way each US can be completed in a sprint and much more managable.

Is this "OK" thinking? Best practice when complete work is 2+ sprints?

Thanks for any input and thoughts!

  • Why are there two gateways? What value do they add to the process that justifies having 4 teams which need to be coordinated to accomplish a (relatively) simple task? Best practice might be to question current practice and find ways of developing value without creating too much overhead. Commented Apr 3, 2023 at 13:28
  • 5
    A user story represents something that is either demonstrable or deliverable to an end user. Is there no way to slice the work in a way that it may not be deliverable and usable in production, but the user can use that slice in a demonstration or test environment and give feedback on that slice of work to the development team? It seems like you may be able to split on creating, sending, and archiving the document, for example.
    – Thomas Owens
    Commented Apr 3, 2023 at 13:41
  • @Hans-MartinMosner Salesforce is in the cloud and the Docgen is in a ultra secure location due to handling military details. Gateway 1 does external login and verifies the payload and gateway 2 handles security only from internal clients (Gateway 1), does logging and monitoring. Overhead is the name of the game for this customer ;-)
    – JohanR
    Commented Apr 3, 2023 at 14:56
  • 2
    I don't understand how this question keeps getting down-votes without any close-votes. This is perfectly on-topic. Questions like this should be the bread-and-butter of this community. Commented Apr 3, 2023 at 17:36
  • @JohanR why 4 teams? Are they internal or external teams? Why 2-8 days of work per team? Bureaucracy maybe? On the other hand, what's your role and what would you like to achieve?
    – Laiv
    Commented Apr 5, 2023 at 7:26

3 Answers 3


You don't want to wait 2+ iterations to deliver and get feedback on things. If you wait too long to get feedback from customers and users, you could invest too much effort in building the wrong thing that would go wasted when you need to do significant rework or even throw the work away.

If you can't deliver something to production and get feedback on the feature in one iteration, the next best course of action is to get something that you can demonstrate to end users, perhaps in a test environment, and get feedback on that increment in one iteration. You can use mock data to simulate anything that you don't have, but by implementing a real slice of the workflow and getting feedback, you can validate a portion of your design and implementation to make sure it's what is truly desired before you spend weeks or months working on it.

I would also suggest looking at your organizational structure. Needing to coordinate 4 teams to implement one piece of user-facing functionality is extremely inefficient. There's probably unnecessary overhead with respect to communication and coordination. I'd also think that competing priorities in the teams may lead to dependent work not starting or finishing as expected. Organizing your teams in a way that allows a single team to take on the full scope of work would probably reduce the overall time to implement, as well.


AS A User I want to...

It is subject for one user story (US), from the user perspective the user requests and gets documents.

Framing the requirements in one or multiple US(s) and launching the feature in a sprint should be unrelated. Since the requirements are user stories the effort is in story points and considering team's velocity gives a sense about the launch time either if there is one or multiple US(s). There is possible to express story points to man-days and have a cost-time-scope overview although unadvisable.

To leverage the parallelism in a multi-team environment, where features developed by different teams depend on each other, the teams have to previously agree on interconnections, then each team develop hard coded versions of external features they have to relay on (so called mock implementations), develop the feature the team has to launch using the mocks and replace the mocks with real features once they are available.

The workflow could be summarized by Plan-Build-Run or "First do it, then do it right, then do it better".


Ideally user stories should take less than a sprint. The trouble is the client doesn't care about your process. They want their big story finished and demoed. not "unfinished" bits.

So break it up internally if you need to. call it an epic and make stories, or split it and only demo the last story.

But don't argue with them that they are asking for the wrong thing or demo 'incomplete' stuff. They won't care.

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.