What is an agile epic, what to use it for, and foremost how?
Requirements. Small, large, technical, business, operational, and researchable. And above all, plenty of them. During four years of ScrumDesk development, we have more than 800 requirements in our backlog. And these are the only requirements that we have decided to implement without any further ideas that would be nice to have. It is, of course, difficult to navigate such a long list without any additional organization of the backlog structure. And this is where Epic comes to help.
Every Scrum or Agile training introduces the term Epic. In training sessions, epics are presented by only using one image, and essentially, they are not even explained assuming their simplicity. It is not rocket science. However, the question emerges as soon as a product owner starts preparing a backlog of the product. How to organize epics? What are they supposed to describe? How to organize them?
Epic is a set of requirements that together deliver greater business value and touch the same portion of the product, either functional or logical.
Agile Epic, similar to the requirement itself (often User story), is supposed to deal with a problem of single or multiple users and at the same time should be usable and valuable.
How to identify epic?
It is no science at all. Start with thinking about a product from a large perspective. Agile epic is a large high-level functionality. Their size is large, usually in hundreds of story points. However, all these chunks of functionalities must be usable end to end. In practice, we have encountered multiple approaches to epic design. Let’s try to see which one is the best for you.
Epics are managed by product management or other strategic roles. For smaller products, Product Owners identify them. Agile epics help structure your work into valuable parts that can be developed faster while delivering value to users.
I. Epic as a part of the product
Epic can represent a large, high-level yet functional unit of the product. For example, in ScrumDesk we have epics BACKLOG, PLAN, WORK, REPORTS. In the app, you can find parts, and modules, which are called the same way as a given epic.
Top epics of the ScrumDesk product
This backlog organization is appropriate when you are creating a product that you are going to be developing in the long run.
Why use this method of epic organization?
- As a product owner, you simply have to be able to orientate yourself in parts of the product and know what you have or have not finished yet.
- At the same time, it is easy to measure progress by parts of the product.
- The Product Owner is naturally urged to change the order of features in the epic, which leads to the creation of rapid delivery of a minimum of viable product increments.
The disadvantage of this method is the lacking view of the user journey It is not visible which parts of the backlog cover what parts of the user value flow. E.g. process from registration, and basket to payment. Each part of the process can belong to a different epic.
Epics, in this case, do not end here, they are not concluded because the functional unit is delivered in the long term. In years. In the roadmap, the implementation of level features of individual epics is planned.
II. Epic as a part of the business flow
This approach is based on the fact, that we know the flow of values, meaning a business process that we can divide into individual parts and then make it more detailed and deliver iteratively. High-level functionalities follow the business workflows.
Epics by the business workflow
For example, an e-shop. Agile epics candidates would be:
- Product catalog viewing – for portraying categories of goods and a list of goods in each category, filtering and searching for goods.
- Product selection – a selection of interesting products such as favorites, comparing, pricing, or adding to a cart.
- The Cart of the products – browsing the content of a basket, comparing, and counting the total price.
- Payment – choice of payment options, total order, total price, shipping, the payment itself, and payment confirmation.
- Product delivery – a visual display of the delivery status, email, and SMS notifications.
The product owner is naturally able to focus on the delivery of the whole customer’s experience. The first fully functional version is then created quite quickly and is subsequently improved iteratively. Epic Payment is based on VISA, transfer, and cash. In the first version, only Visa payment will be delivered, transfer and cash in the next one.
The development of epics takes a longer time in this case. It does not usually make sense to close them, as they will be further elaborated in the future by other features. Business easily understands the state of the implemented application (e-shop) which simplifies communication and significantly improves cooperation between IT and business. It is important to use commercial terms rather than technological ones.
III. Project as epic
Do you deliver products to a client in various phases and various projects? In this case, it may be easier to create epics according to projects or the project’s phases.
Epics as project or phase
Such epics are usually considered finished (closed) when the project is delivered. The advantage is obvious. There is an absolutely clear state of implementation of the project. Participants and stakeholders have excellent transparency. At the same time, stakeholders can focus on preparing for the next phase of the project.
On the other hand, it can be quite difficult to keep an overview of the functionalities units of the product itself. The state is more perceived by architects rather than the business itself. In real life, we also came across seeing this way to lead to a change in the company’s focus, or even to the degradation of its vision. A company that once wanted to act as a product and solution maker became a company fully listening to clients. Their products became a ‘toy’ in the hands of clients which led to people leaving teams because they have lost the personal connection with the product. They often lose the power to say NO.
It is also practical to use themes for further categorization of requirements. This creates a virtual matrix, in which each requirement belongs to a certain product set and also might belong to a business theme that is communicated to clients. In ScrumDesk we use, for example, themes for identifying clients who had requested larger sets of features, and we, after all, decided to include them in backlogs. As a product owner, I know how to communicate the status of requirements with a client while still keeping my eyes on the implementation of the product itself.
Epics and Themes
Themes in the product world are often determined by top management at strategic meetings and these topics are subsequently implemented in multiple value streams supported by multiple products. An example of such strategic themes can be 3D Maps, AI (Artificial Intelligence) in risky investments, and traveling without physical gates and cards.
In addition to business logic, an application has many parts that create a basic core of a product, but a customer rarely notices them.
First of all, you need to think about and register, for example, the design of architecture, suggestion of UX layout of an app, initial frameworks, and technological preparation. In later phases, the functionalities are still touching the entire product at once. E.g. logging, error handling etc. In ScrumDesk we had an epic called #APPLICATION for such requirements.
When we started four years ago, we decided to keep all bugs in epics titled #TECH. Symbol # indicates artificial epic.
Later we changed this strategy and now we are trying to put every requirement, regardless of its type, under the right epic, as the epic either repairs or expands, improves from the technological point of view.
Epic and business value
In Agile, each requirement should deliver additional business value. However, in the case of more complex applications, it is almost impossible to evaluate the value supplied at such a low level. In this case, it is easier to determine the business value at the level of epic. Epic then can analyze, suggest and prepare ahead of implementation itself beforehand.
It is also possible to create a business case and consequently the business value itself. Such an approach is recommended, for example, Scaled Agile Framework, in which the epic adds value to the selected value stream.
Epics in SAFe
How to prepare epics?
Product Owner prepares epics in advance, prior to planning and implementation.
For good preparation he needs support from multiple people:
- an architect for a rough design of the architecture that is needed to implement the epic,
- stakeholders, for whom the functionality will be delivered, for business value determination and business case,
- UX Designer to work out framework principles of interface design and usability of the epic,
- People from service and support for a good design of epic from the operational perspective,
- And whoever else is needed
Preparation of an epic can, and often has a different process than the requirements themselves. In SAFe ‘Portfolio Kanban’ is recommended for the preparation of epics. Therefore, a separate Kanban board with multiple statuses exists on which the momentum of the epic realization is transparently displayed. This creates space for regular meetings of a small team preparing requirements ahead and continuous improvement of epic details.
Portfolio Kanban systems for epics management
The Product Owner basically works in two-time spaces. In the first one, he prepares epics for the future, and in the second he contributes to the implementation of already developed epics.
How ScrumDesk helps with epics?
ScrumDesk supports epics from its first version. As we use ScrumDesk for the development of the ScrumDesk, we identified and tried different approaches to backlog organization. In the first version epics were just titles, later we added possibilities to:
- add more details in the description of the epic,
- visualize epics as colored cards in user stories map,
- added an option to track the business value, risk, effort (as an aggregation of child requirements),
- break down epics into features and/or user stories to manage complex backlogs,
- track comments and changes,
- attach files (i.e. business cases),
- possibility to add the timeline for epics and features with the support of agile roadmaps displaying not just plans, but comparing them to reality as well.
- Epic by technology layer. Database, backend, frontend. Functionality is not covered end-to-end, it only supplies parts of it.
- Epic by product version. The product version is a set of properties from different epics. Unlike the epic, the version has a timeline as well.
- Epic by a customer (stakeholder) to which part of the functionality is being delivered. If you need to evidence the customer, evidence it in a separate attribute and organize the epics according to the procedures above.
- When the product assumptions change, the form of epic organization will not readjust. Adapt and select appropriate approaches as needed. Do not be afraid to work with the backlog and change it so you can orient quickly, you can choose other ways of epics organization and especially to have it transparent for the team as well as stakeholders.