How I think about epics, features and user stories
Epics, features and user stories can have different relationships.
They can, and often do, have a hierarchical relationship where feature is a bucket to group user stories and epics are buckets for features. This means that, conceptually, any given user story only relates to one single feature and that feature can only be part of one epic. This relationship leads to two problems; either the product is developed as individual pieces not a coherent whole, and/or the mental models of those doing the work doesn’t fit with how we organise the work, both of which creates confusion. So, it’s not the best relationship.
I think there’s a better way to think about the relationships between epics, features and user stories. Think of them as different types of things that are interconnected rather than as the same type of thing in hierarchical relationships with each other.
So, that means…
Epics are long-standing capabilities that evolve over time to meet business and user needs. They are meant to provide context and set direction; that’s the job they do. Roadmaps for mature products might be organised by epics/capabilities to show how the product is developing in a balanced way across all epics. We can associate features with multiple epics to show how a feature is contributing to improving that capability, but an epic isn’t a bucket for a subset of features. And there isn’t a one to one relationship between a feature and an epic. Epics are never finished, which fits better to a product way of seeing the world.
Features are combinations of functionality. They can be added, changed or removed to improve the value a product offers. Sometimes a user might interact with a feature but not always. A single feature could contribute to multiple epics or just one, or none. That’s because features are independent of epics and do a different job, they are about how things work.
User stories are boundary objects. They are meant for passing information between different knowledge domains, such as user research, design and development, in a way that makes sense to all of them without translation. User stories working as boundary objects are flexible enough for different roles to get what they need from them and yet robust enough to maintain commonalities that all roles understand. This makes them far more powerful than just being another way to specify elements of a feature. And just like epics, user stories also don’t have a one-to-one relationship with a feature. Telling the story of a user isn’t just about how they should use a single feature because no one uses features in isolation. Understanding the story of the user isn’t just about what to build, it’s about how to affect the people who use the product. Good user stories refer to the past and future, they explain situations and motivations, they inspire possible changes in user behaviour.
Now, rather than epics being nothing more than buckets for features they are a distinctly useful thing in themselves. They show the capabilities of the product developing over time.
And rather than user stories being feature requirements-in-disguise they have a specific function. Their job is share knowledge between people and roles.
Epics, features and user stories are three different things, performing three different roles, that, when used in unison, help to make sense of work from different perspectives.