What is an Epic in Agile and How to Write It?
Scrum has been in use for a while, and organizations benefit from it. So many enterprises have achieved success with Scrum. The same holds for Agile too. Agile has helped many organizations deliver customized solutions and enhance user experience. The iterative method adopted by Agile for product management brings continuous improvements to processes. With Agile, Product Managers get better control over their products and enable them to deliver high-quality products resulting in customer satisfaction. Since, with Agile, Product Managers can visualize their products more effectively and makes it easier for them to predict risks and plan the ways of their alleviation. An essential part of Agile methodology is Epics. Organizing their work and creating a hierarchy in the development process is the foremost task for any Product Manager. Epics are helpful in both. But let us first understand what an Epic is in Agile.
What is an Epic in Agile?
An Epic in Agile methodology can be described simply as an enormous task that can be broken into smaller parts called User Stories that share a broader purpose of strategy. An Epic may involve many tasks, Sprints, or even multiple teams and products with a specific value because it describes the customer's needs at a higher level. Since Epics encompass multiple Sprints, more often than not, they are delivered over a set of Sprints. A significant feature of Epics is that they are flexible. User Stories can be added or removed depending on the customer feedback and development. Hence, the scope of an Epic can be widened or narrowed as necessary by the above factors.
Creating Epics is to break large tasks into smaller ones to make completing products easier. These small tasks are also easily deliverable, ensuring that the customer is delivered value regularly. Epics help teams to take up work in small segments while working toward a larger goal. When many Epics have a common business goal, they are clubbed into a wider body of work called theme. So, in Agile, Epics fit between User Stories and themes. A theme also represents a high-level strategy of the organization to put this strategy into practice. A theme is first split into multiple Epics, each further split into many User Stories. Therefore, when this high-level strategy or theme is broken into Epics, it helps keep the teams' daily progress connected to the broader business objectives.
Now that we know what an Epic is in Scrum and Agile, the next logical step is understanding how to write Epics in Agile. Let's see how a good an Epic should be written in Agile.
How to write Epics in Agile?
It is always a good idea to write User Stories after writing an Epic. Once you have written an Epic, you can work on details when writing individual stories. You can ascertain the scope of the product at an early stage. There are multiple ways of writing an Epic, but we will delve into these steps.
Three parts are required in all Epics and stories. They are Name or Label, Narrative, and Acceptance Criteria. Here, it is essential to understand the difference between an Epic and a User Story. An Epic is a significant task that a single Sprint or team can not deliver. Instead, it is a set of User Stories spread over multiple teams and Sprints. So, let's go through the steps of writing an Epic.
Name or Label of the Epic:
Label or name is the title of the Epic. There is an absolute need to give an exact name to an Epic before starting to write it. The name should indicate what the Epic contains or what it is about. It can be a short phrase outlining the broader strategic objective. For example, the Epic name could read something like "easing the machining processes." Here, there is complete clarity and no confusion about the strategic goal, which will considerably reduce the chances of miscommunication among the team members. This is why giving a proper name or label to an Epic is essential.
Writing a Narrative to describe the Epic:
The Narrative briefly describes what is expected to achieve from the Epic. It should be easy to understand for people who know the topic. The Narrative should contain at least three things to describe the Epic.
Who - This product is to cater to customers' needs or attract new users. Are you adding features to an existing product to meet customer requirements, or are you launching something new to benefit new customers? Overall, the Narrative should describe who this product is for.
What - What is the objective of the project? What do you want to achieve from it? These questions must be answered while writing an Epic.
Why - Why is this product taken up? What value will it add? It is to emphasize the need for the product. It should describe the value behind the objective.
Set the scope of the Epic
Once you have written the Narrative, you need to set the range of work to be done and the boundaries within which the Epic will be carried out. If your team is clear about the scope, there will be little chance of it going off-track. Looking back at the name we had provided to the Epic in our example, "easing the machining processes," the scope can be defined by specifying which machining processes are to be focused on and which steps can be removed or simplified. When the scope is clear, it will save time and effort, with the focus only on deliverables.
Define the criteria for the completion of an Epic
Your team should know when the completion of the Epic would be defined. What would be the Acceptance Criteria for deeming an Epic complete? Acceptance Criteria is a list of requirements that describes what is to be built and that your team would need to approve. Acceptance Criteria give you the limits of the story. They are a sort of checklist for the team to check if they have satisfied the feature requirements so that a story can be delivered, but they do not contain any suggestions for implementation. Acceptance Criteria are not tasks and do not instruct on the process of building a feature or product.
In our example, Acceptance Criteria could be like this:
- End-users approve of the changes in the machining process.
- There is a reduction in time loss.
- The productivity has improved.
Breaking an Epic into User Stories
The last step in writing an Epic is breaking it into User Stories. You have technically completed the process of writing an Epic, and breaking it into stories is the next stage. The reason for adding this stage here is that before you start implementing the Epic, it is essential to break it into smaller stories. You will get the child stories of an Epic from its Acceptance Criteria. Like in our example, there were three User Stories. There can be more or fewer stories in every Epic as per the Acceptance Criteria.
So, with an example, we have described how to write Epics in Agile. There is a fragile line between a big story and an Epic. Generally speaking, if a team estimates some work in weeks or longer than that instead of hours or days, it is considered an Epic and should be broken down into smaller stories. The above way of writing an Epic is generally used for user-facing Epics, i.e., where some people are directly benefitted. Still, there may be Epics from which end-users do not benefit directly. This system of writing an Epic can be used for them also.
References
- https://www.wrike.com/agile-guide/agile-Epics-guide/
- https://www.productplan.com/learn/how-to-write-an-Epic/
- https://www.linkedin.com/pulse/4-steps-writing-good-Epics-stories-randy-chevalier-csm/
