Should we have "general high-level" user stories that spawn out more "more specific detailed lower-level" user stories?

Question

For software user stories, Does it make sense for user stories to spawn out other user stories? In other words, Would it make sense for us to document more "general high-level" user stories, which would then allow us to derive "more specific detailed lower-level" user stories?

Answer 1

This is a normal by-product of refinement. Part of refinement is decomposing a specified need into something that can be delivered in a reasonable amount of time. For example, if you're using the Scrum framework, each item in the Product Backlog is something that should be deliverable in no more than one Sprint. Other frameworks have similar expectations for size of work.

Sometimes, a hierarchy of Epic and Story is used to refer to this, as well. However, there are different definitions. Some people see an Epic as a large, unrefined Story that will be decomposed into these smaller pieces. Others see an Epic as a container for multiple stories (or other units of work) for visualization and tracking purposes.

Answer 2

Yes, it makes sense. It's somehow inevitable since things start of with a big idea that is then decomposed in smaller and smaller actionable items.

I think you are talking about epics (see more details here: Epics, stories, themes, and initiatives). The idea is that your user stories have a small or large granularity and everything in between. People usually give them different names as shown in the previous link, others just call them Product Backlog Items.

However you call them, you can have them all in the backlog. The main idea though is to refine the backlog so that you split them into smaller and smaller pieces of work that can then be implemented (see INVEST for ex).

Answer 3

Adding to what Todd mentioned, I think that having a user storie that would be split into smaller ones is just confusing. Think about it from a QA perspective: they can't close the big story unless the close the smaller stories.

A better way of looking at it is to have an epic for that "big user story", and then file the stories and engineering tasks below that epic.

I'm definitely talking from a JIRA perspective, on how they structure things.

Answer 4

Another observation: *"as you proceed along this process of refinement, the 'stories' will quite-naturally cease to be 'user' stories." You are now deep-diving into the world of "how the existing software now works," and into "how now to change it, without utterly breaking it." This evolution of project focus is both normal and essential.