In Agile Project Delivery, work is broken down into manageable pieces. The smallest of these is a User Story, describing a new feature or the upgrading of existing features. Each Story commonly represents a part of a larger group of functionalities which is called an Epic. Epics deliver substantial value to product users, thus the elevated naming convention. Epics will likely deliver multiple User Stories, lifting the product to a higher level.

Imagine a web application with a set of free features. An Epic would be to set up a payment system for that application. Such an update would unlock many more possibilities for the expansion of services. The completion of this Epic would enable the introduction of more unique features, available only for paying customers; the creation of these ensuing features would in turn, likely become new Epics. As with User Stories, Epics may be dependent upon prior work or implemented in parallel. Many factors influence the way an epic can progress, this being a cornerstone of Agile itself.

There is a bigger goal behind an Epic in comparison to a Story, so it should be carefully formulated. When you start to describe an Epic you are essentially summarizing a new state of your product and are beginning to plan that new state. In the description, you will imagine the purpose of the new function/s, which users would be affected, what new goals users would achieve by using your product, and the benefit/s derived by the business.

‍

A Detailed Overview

Once you’ve envisioned what you need to accomplish, refinement of the vision will now be needed.

Outlining the logic of the User Experience (UX) and conceptualizing the User Interface (UI) processes change from writing to drawing, the next steps are to produce flows and wireframes. Using imagination and creativity, the exercise involves imagining high-level inputs and outputs, the logic of the application, possible integrations, and how all parts of the application are/can be affected. You will want to avoid getting carried away by not trying to prepare the full details of solutions at this point. This will come at the latter stages once the Epic is described and goes to implementation.

After you have an understanding of what the product is to become and once the Epic is implemented, next would come the breaking down into individual Stories. This part is often tricky and you’ll likely not get the division of things right with your first attempt. Remember that a User Story needs to have independent functionality. At the same time, it should be small enough to be easily managed. Your goal, after every implemented Story, is that you have a working product. This may become a challenge when imagining the Epic and layering it into smaller pieces. You may, however, find that the product may not necessarily be market-ready after every Story.

Imagine a new form in your application requiring user input, designed to collect user data to be successfully processed. The form would contain many text fields, some of those having dependencies on one another, pulling on inputs with dynamic values from other parts of the application, and additional inputs for files to be uploaded. Finally, the destination of all that compiled data would then perhaps be another system that is tracing various applications. Agile isn't a science, and you just read how the complications may require flexibility concerning change.  

For both users and the business, the entire process needs to work seamlessly or it won’t make the most sense. However, implementing the whole Epic would take weeks of development, thus splitting it up brings better management. To keep the application functional after every Story, you could split the complexity the following way:

• Group the data inputs into several logical pieces. Set a few text fields per group, file uploads as separate groups, and then integrate other parts of the system as independent groups.
• Prepare initially what appears to be the simplest input and output as the first User Story. This will frame the entire process, enabling the user to input something basic, getting the output with a success message, as an example.
• The remaining input groups can be added to ensuing stories that would extend input fields and output results.

With this approach, the application process would be working after the very first Story and potentially can be shipped to the first group of end-users. In the following iterations, more enrichment will bring meaningful steps, while each remaining piece waits to be worked into the next Epics and User Stories.

‍

How to Finish an Epic

With a certain goal and value for users in mind, it makes sense to finish the epic when the goal is reached. A frequent practice, however, is to consider epics as some kind of stream of work. For example, work on user profiles would be tracked in a “Profile” Epic, everything related to payments tracked in a “Payments” Epic, and so on. Seeing some mistakes from watching others it is key to cease the Epic at the right duration, outputs, and completion, so your Epic doesn't seem unending, and more so you stick to the original purpose.

If you are used to categorizing your work in such streams but would like to switch to more contained Epics, you can try limiting work on these streams by versions. For example a “basic profile” Epic could contain the first few features, an “advanced profile” Epic would then contain improvements to those features and more, and iteratively carried on. This will help you organize your backlog and releases more transparently.

‍

Reach out for more information.

Nikita Lamonov, product owner