While there are numerous ways in which Agile software development teams will describe the work they need to do in order to deliver business value to their customers, user stories have become something of a staple choice.
In essence, user stories represent what needs to be built and are also prioritized based on business objectives, strategy, as well as based on importance, efforts, needs and other factors. When a user story is too big, it's referred to as "epic".
However, this size aspect is just scratching the surface of the Agile project management epic and this article will be more than just surface stuff.
Epics by definition
In order to further explain epics in Agile, we must first take a look at user stories themselves. As mentioned before, user stories are requirements originating from clients or users that represent a product feature that should be implemented.
User stories are based on a simple agile user story template. For instance, "As a <role/user>, I want <goal/desire> so that it ". Aside from the template, user stories can be described as a simple phrase as well. Simply put, stories represent features that can be added in the next iteration, in order to enhance the overall value of the finished product.
Now, epics are also stories that are too large to be implemented in a single iteration. Therefore, epics are broken down into smaller stories so that they can be added in the product itself. What's more, epics tell a bigger story that focuses on the original idea designed to represent a desired outcome for the finished product. With that in mind, epics are kept separate from the other backlog items but still consulted in order to construct a hierarchy for the backlog items.
Epics in the backlog
In the Agile software development, a product backlog represents the list of features, changes, bug fixes and other relevant activities that a development team may deliver, in order to achieve the desired outcome for the finished product.
However, just because an item is located in the backlog, it doesn't necessarily mean that it will be delivered. Instead, it's rather an option that the developers will consider for reaching the desired outcome and not in any way an obligation for them. Backlogs can contain various formats of which the most common items are indeed user stories.
The main purpose of this is to enable a cheap and efficient way to add or remove features during the Agile software development. In addition, backlogs serve the purpose of helping the teams communicate, as well as plan on what to do next. But how do epics fit in all of this? Simply put, Scaled Agile Framework (SAFe) developed a series of backlogs to divide and even replace a single product backlog, in order to establish a hierarchy. For instance:
- Portfolio backlog - This log contains the various initiatives, also known as epics, an organization is currently considering.
- Solution backlog - This backlog contains high-level backlog items, also known as enablers and capabilities, designed to represent an aspect of a solution.
- Program backlog - This backlog contains lower-level backlog items, known as features, which also represent an aspect of a solution.
- Team backlog - This backlog contains backlog items, such as user stories and other items that developers are currently working on.
That way, epics are kept separated from other backlog items because they are too large, oftentimes to a point where a single epic can encompass multiple projects. Instead, they are referred to as guidelines for reaching the end goal or the main objective for a finished product.
Confusion regarding the epics
There's a lot of confusion going about the epics and their role in the Agile software development. After all, if epics are just large user stories, then why not treat them as regular backlog items? The main reason epics aren't treated as such is because it contradicts the entire purpose of Agile methodology.
That purpose is to divide the workload into smaller, time-boxed segments called sprints so that the software itself can be developed, tested and revised organically. That's why an epic gets divided into stories. However, the role of epics is still important nonetheless. The main role of epics is to maintain the bigger picture or a vision of the project's finalization while allowing teams to discuss or even argue over how to treat individual requirements properly.
In other words, epics allow the teams to brainstorm different ideas without losing sight of what the end product should look like. The entire purpose of establishing a hierarchy is to help prioritize work that will deliver the most value to the end-users in the fastest and the most reliable way, which is what Agile is all about, in the first place.
Clearing the confusion
In the end, it comes down to your understanding of the epics themselves. When an epic's purpose is clearly defined within an organization, it becomes much simpler to comprehend it, as well as leverage it properly. In order to simplify things and clear out the confusion, consider epics as a means to keep track of loosely defined ideas in your product backlog.
The user stories directly related to an epic will provide an idea for a solution that must be delivered, as well as represent the options you have at your disposal that will help you satisfy any specific needs. When an epic is split into individual user stories, it becomes easier for your teams to refine the requirements during the backlog grooming process.
However, make sure that the teams don't view epics as more than large user stories or that they spend too much time creating complex mechanisms that will differentiate epics from stories. Both of these activities simply result in a wasted effort, whereas time spent tracking the information could otherwise be spent on more important activities.
Epics play a vital role in the Agile software development. Their purpose is to create a clear picture of what the desired outcome of the project should be or look like at the very least. In addition, epics must be conceptualized separately from user stories they consist of but still viewed from the requirements point of view. That way you can create a hierarchy that will ensure that there's a focus on the value in the product being developed.