Context: analytics software

The customer wants to see graphical elements A,B and C in the same area of the screen. Selecting something in A will affect B and C. Similarly, selecting something in B will affect A and C. In other words, A,B and C are dependent on each other and represent different views of similar information.

How do I describe something like that in the user stories? I can create one big story describing the whole scenario, but it would be nonsense (should be small, testable etc.) Should I create 3 stories describing what user wants to see and then separate stories describing logic between those, then combining all of this into epic or is there a better way to do that?

2 Answers 2


Take it to the team.

There are no specific rules as to how to split this case yours; there are only general recommendations on how to write useful user stories (like INVEST, and 3Cs). At the end of the day it all depends on context. You and your team know the context so you should decide together how you will split a larger feature into smaller pieces.

As part of the refinement of your backlog, the team comes together to understand the work that needs to be done, split it in smaller pieces, define acceptance criteria, estimate it, etc. You need to decide together how you will do this work and then create the user stories to represent it:

  • maybe you first create A, then B, then C, then add a story to make them work together;
  • maybe you start with A, then you add B and at the same time make it work with A, then you add C and at the same time you make it work with A and B;
  • maybe you create A and B together, then C and make it work with A and B;
  • maybe you create all of them together if the work doesn't take too much time;
  • etc.

Decide together. You know best what you are dealing with and how to plan doing the work.

  • Thank you. That's the approach we are taking. I found it is generally difficult to create user stories with the logic built like a collection of interconnected Russian dolls. My general approach in this case was to build 3 initial stories for A, B and C and then pile up of the user stories describing logic of connection between them (aka "filters") I am not entirely sure if that's right or wrong, but I could not find a better way so far.
    – Shimon
    Commented Feb 15, 2021 at 15:38

Rather than describing the implementation, describe the purpose. What is the goal that the user wants to accomplish, and how to recognize that goal has been satisfied.

Leave the implementation to who implements the code. They shall discover the best implementation while coding, starting with the simplest case and iteratively adding complexity to it.

This way the design isn't based on guesses (plans), but real life feedback.

  • In my case, it will not work, unfortunately. The client is insisting on knowing what exactly he wants and describes not only what, but how, so I have little room to do it by the book. But the biggest challenge is that the convoluted logic has interconnected logic between the elements based on the user roles. I tried to separate by role initially, but it did not work either because role 1 and 2 can use A and B in one way and role 2 and 3 can use it differently, yet role 4 can use it in yet another way, but only if role 1 is not affected. The only way that "worked" was described by first answer.
    – Shimon
    Commented Feb 15, 2021 at 15:46
  • Being effective means delegating the implementation to the people in charge of it, and trusting they will come with their part without watching them all the time. Commented Feb 16, 2021 at 6:34

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.