What is a User Story/Feature/Epic in Agile? A missing introduction.
In this article, I’d like to provide an explanation what is a story, feature, or epic, and explain their differences. And give some background why I think this way.
To start the discussion, let’s talk about how we humans convey information to each other about objects and processes. Yes, that is very simple: we tell stories to each other. The story highlights perspectives that are interesting to the listener at the moment. Let’s take a hummer as an example, and you can tell the following stories:
- Internal structure perspective
- Story: a hammer consists of a head, handle, and grip.
- Story told: From a manufacturer to a procurement department
2. Functional Perspective/User Perspective
- Story: a hammer is a tool for driving nails into wood or other materials. It has a function.
- Story told: From a carpenter to his apprentice.
3. Manufacturing steps perspective
- Story: to build a hammer, you need to forge the head, craft the handle, assemble the parts, add a grip, polish, and test.
- Story told: From a manufacturer to his employees who build hammers
4. Mythological perspective
- Story: a hammer is a symbol of strength. In Norse mythology, Thor’s hammer represents protection and power.
- Story told: From a graphical designer to his team while creating a logo for a mechanical shop.
5. Historical perspective
- Story: The hammer is one of humanity’s earliest tools, with stone hammers dating back tens of thousands of years.
- Story told: from an anthropology professor to his students
The most common perspectives in software engineering are Internal Structure, Functional/User, and Manufacturing steps.
Get DroidM’s stories in your inbox
Join Medium for free to get updates from this writer.
Coming back to the stories in our task-tracking systems. When we build software, stories play two functions:
- Stories convey requirements to the systems
- Software is built by people, and it takes time. So, stories help organize people’s efforts into meaningful steps.
Different perspectives and approaches were popular at different times to describe the requirements for the system. For example, use cases were popular in 2000x, and use cases were stories told by software engineers to other software engineers. Those stories contained a lot of technical knowledge about the system and its components. And very often, the intent of what is required for business was missed from those stories.
The industry has evolved. Currently, the standard is for the users to tell a story from the Functional/User Perspective, focusing on what is required for business or the user’s role. Those stories are abstract from the system components and technical details.
As for the second function — work organization — before the widespread adoption of agile, the typical way of organizing work was by modules and work items: collecting requirements (as statements), breaking down requirements into modules, assigning teams to the modules, and starting to create work items, like designing, building a document, coding a function, creating a test case, etc. Multiple problems with this approach are worth a separate article; the main problem is that it is very hard to build an e2e consistent functionality and deliver value early. So, the industry reacted to this and invented the functional decomposition. So, if a story is big, we will call it an Epic, and then we functionally break it down into smaller Stories that can be implemented by the team and delivered to the customer as one iteration.
Coming back to our hammer, the epic would sound like this: “Carpenters need a tool to drive nails into the wood conveniently under rainy conditions.” The stories will cover “basic impact delivery functionality,” “nail removal functionality,” “anti-slip handle,” and “rust resistance.”
In this example, we take a function and break it down into smaller pieces. It is common in the industry to break down user functions into three layers: Epic, Feature, and Story. But the key here is that each layer is a sub-function, not a work item. You don’t decompose Epic into a Desing Hammer, Build Hammer, or Test Hammer.
So, the difference between Epic, Feature, and Story is only one — the size.
To summarize, a story in software engineering is a story told by the system’s user to its developers. The user looks at the system from a functional point of view and describes the function and the value that this function brings. Stories of different sizes are called differently: Epics are the biggest functions, Features are medium sizes, and Stories are the smallest that can be delivered by the team in a single iteration.
In the following article, I will describe the relationship between stories and tasks.
