Developing Epics For Product Owners

The term ‘epic’ in agile refers to a large user story that has not yet been defined in detail. Typically, an epic will cover a single business process that must be fully completed as a whole for the business value to be realized. These user stories are described as epics because they will require refining over multiple cycles before they can be considered done.

How to Use Epics

The use of epics is very helpful to the Product Owner because it means that they can describe and note down the high-level functionality of the user story, but they do not have to dive into the detail yet. The Product Owner will initially use the epic as a container to broadly capture the requirement and will add this as an item in the Product Backlog. It acts as a placeholder until it is turned into a group of fully formed user stories at a later stage.

Epics will always be placed lower down in priority in the Product Backlog by the Product Owner. The reason for this is that, as soon as they become high priority items, the first step will be to break the epic down into user stories that are of a size that can be delivered within a sprint. Because of this, the Product Backlog is sometimes referred to as having the shape of an iceberg, with the larger epics at the bottom and the most granular and well-refined stories at the top. Both epics and user stories can be divided up into smaller pieces of work, and this hierarchy can be stretched to whatever level is necessary and makes sense. In other words, larger epics can be split into smaller epics, and these are then split into stories, which can be further refined into smaller stories, and so on.

Techniques for Collecting Epics

There are a number of methods that can be used to pull together the information that is needed to define epics and the subsequent collection of broken down user stories. Some of these methods are described below.

Interviews

Interviews tend to be the default technique used to collect user story requirements. However, while this is one of the more common methods, it takes a certain amount of skill to be able to use this process effectively. The reason for this is that the users themselves are not normally very clear about what they need. In order to clarify exactly which features would help them to simplify their tasks, the Product Owner must be adept at asking the right questions and following up with more context-specific inquiries, while at the same time being careful to keep the query open-ended enough to tease out any important pieces of information.

Observations

A good way for the Product Owner to understand how users use a system, and to find out what changes they need, is to watch them using it. This can be done either by simply going along to their workspace and observing them while they perform their daily tasks, or actually asking them to demonstrate how they would carry out a specific function. Both these techniques can provide valuable insight into the actions that a user will take, and can sometimes uncover scenarios that would otherwise have potentially remained hidden.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: