What is fascinating about the User Story is that it’s an open-ended framework that can be used well or it can be used poorly. The most important thing is keeping the User Story in problem space and to link it back to your value proposition and problem scenarios. Two reasons for that:

• It helps to debug when something goes wrong by tracking back to the origins of the story and what problem it meant to address
• It facilitates the important discussion with the team so they can reach a shared understanding of what the problem is and together conclude what is the best way to solve it

So you need to write your User Story from the perspective of the problem and don’t put the solution in it, leave that to the team conversation.

Unpacking the Narrative

What is the right level of details (nesting and child stories under epics) you need to get with your stories?

My recommendation is to start at a high level and keep your stories in the problem space. This will drive a lot of conversation that will be used to break them down.

Another way is to start with high level problem-focused stories and list your acceptance criteria with the team and when the list grows to 6 or 8 items, probably it is time to consider splitting the story.

There are other factors that can play a role in the story granularity like the need to quickly push a new feature to the market to start an early learning process, polish an existing one, the time and cost constraints… etc. All those factors affect story prioritization and thus splitting it into child stories to focus more on the most important ones within our constraints.