{"id":441,"date":"2021-04-20T10:56:47","date_gmt":"2021-04-20T07:56:47","guid":{"rendered":"https:\/\/hygger.io\/guides\/?p=441"},"modified":"2021-12-06T13:24:02","modified_gmt":"2021-12-06T10:24:02","slug":"epics","status":"publish","type":"post","link":"https:\/\/hygger.io\/guides\/agile\/project-management\/epics\/","title":{"rendered":"Agile Epics"},"content":{"rendered":"

Writing epics is the most basic and crucial task when you are trying your skills in\u00a0<\/span>Agile project management<\/span><\/a>.<\/span><\/p>\n

\"what<\/p>\n

The ability to write good epics will positively affect your team collaboration and overall results. Therefore, product managers should pay enough attention to creating Agile epics, slice them down, and prioritize the backlog to have a smoother development process and easy shipment. What defines an epic? What are examples of epics? How do you start an epic? In this post, we offer some interesting facts about the meaning of an epic in Agile; the difference between epics and features, as well as ideas on how to write epics right.<\/p>\n

What Is an Epic in Agile?<\/h2>\n

An epic is a big story. Most likely, when you think of epics, you immediately recall literature. And this is quite logical.<\/span><\/p>\n

In terms of software development, the bigger the user story, the more likely you\u2019re dealing with an epic. This is the most vivid difference between epics and\u00a0<\/span>user stories<\/span><\/a>\u00a0in Agile.<\/span><\/p>\n

There is no need to try to thoroughly understand should this be an epic or a story. If this provides business value and needs to be on your backlog, then this is a story. However, it may also be an epic, because it\u2019s big. So, in the Agile environment, you can use the following definition:<\/span><\/p>\n

An epic is a user story that can not be completed in one sprint.<\/i><\/b><\/p>\n

This epic definition does not rely on the use of story points estimation<\/a> and it looks independent of the particular team\u2019s velocity.<\/p>\n

What Are the Roots?<\/h3>\n

Mike Cohn was the first one who introduced the concept of an epic as a large user story in 2004. The book where he describes it is called “User Stories Applied For Agile Software Development”.<\/p>\n

An Epic and the Agile Development Process<\/h3>\n

As we’ve just defined, according to the Agile development hierarchy system, an epic is settled between a theme and a user story. And it’s important to note that a theme is the high-level strategy of the team for its product.<\/span><\/p>\n

To realize the strategy turning it into an actionable\u00a0<\/span>project plan<\/span><\/a>, team members must take some essential steps. Firstly, the Agile team breaks the theme into smaller epics. They can be considered as smaller strategic plans. Secondly, the team must split every single epic further into stories. Each user story is a small unit of development work that will let users complete a task in your product.<\/span><\/p>\n

\"Agile<\/p>\n

Epics First, then Stories<\/h3>\n

When project managers (especially PMs without experience) start planning an Agile project, all their user stories are likely to be in epic form. During prioritization, the most important epics will be broken down, down into smaller stories. The Product Owner will prioritize these stories and the ones with the highest priority will move to the next sprint.<\/p>\n

Epics do not clutter the backlog and this is like their best advantage. When you keep most of your user stories in epic form, you simplify the way the PO manages the product backlog. Epics also let you keep your development team from wasting their time hashing out a number of stories that might never be prioritized at all.<\/p>\n

What Are the Benefits We Can Expect?<\/h3>\n

With the help of Agile epics, we can keep track of large ideas in our backlog that are not clearly defined without the need to overfill the backlog with numerous items. At this stage, during the backlog grooming meeting, the Agile team can break the epic down into smaller user stories.<\/p>\n

Epics benefit Agile teams, as they allow for establishing a hierarchy for the backlog items where the epic means the original idea (often related to the outcome). The user stories involved in the epic represent different aspects of the solution you need to deliver.<\/p>\n

It also allows us to see the concept of themes that are used for grouping stories related to the same topic. The concept of themes is often used to group stories that were identified separately and can filter sorts to define what user stories to group into a certain sprint or delivery.<\/p>\n

What Are the Possible Pitfalls We Should Expect?<\/h3>\n

Epics in Agile are also connected with some pitfalls we should care about in advance. Your Agile team can overcomplicate the use of epics by considering them as more than just large user stories. This becomes apparent when the team members build complex mechanisms to differentiate epics and stories and implement extensive tools to monitor epics separately from other backlog items.<\/p>\n

These actions lead to the wasted effort that will result in more finely grained backlog items. The team can also strive to estimate epics even though these items are usually quite unclear and prone to more uncertainty, which decreases the likelihood of reliable estimates.<\/p>\n

Agile Features vs Agile Epics<\/h3>\n

An epic vs feature is a topic that can often be confusing. You can consider epics as product major versions, projects, or complex initiatives. If you represent a product, where several (or many) teams are working on it for a year or more, it makes sense to structure the backlog on epics, features, and user stories. If your product is less global and involves only one team of 10\u201312 people, it makes more sense to simplify the work and have only two levels of details for the backlog: features and stories. This depends on the product, your preferences, and your needs.<\/p>\n

Agile Epic Example<\/h3>\n

Let’s imagine there is a company whose goal is to organize excursions on a sea submarine. The company runs dozens of excursion launches per year, and every single launch requires many person-hours to complete. This sizing is right for an epic.<\/span><\/p>\n

An epic, \u201cJune 2022 submarine excursion launch\u201d will include user stories for routine work items and the stories aimed to improve core aspects of the submarine launch, from clients buying tickets to the launch of the marine itself. It means that at least several teams will contribute to the epic by working on a wide range of user stories.<\/span><\/p>\n

Here’s how the team supporting the purchasing of tickets for the June excursion launch can structure their epic:<\/span><\/p>\n