This article looks to discuss how to Define Epic in Agile and looks at the role of the Product Owner within this process. The article covers how to use epics and the methods used for collecting Epics.
The History of Agile
A 59 Seconds Agile Video Animation
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. This business process must be fully completed as a whole for the business value to be realized. Large user stories are often described as epics. This is because they will require refining over multiple cycles before they can be considered done.
Define Epic in Agile: How to Use Epics
The use of epics is very helpful to the Product Owner. This is because it means that they can describe and note down the high-level functionality of the user story. However 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. This Epic will be added 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.
Define Epic in Agile: Priority in the Product Backlog
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. These User Stories 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.
The larger epics are 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. This hierarchy can be stretched to whatever level is necessary and makes sense. In other words, larger epics can be split into smaller epics. These smaller Epics are then split into larger stories. The larger user Stories can then be further refined into smaller stories or tasks, and so on.
Define Epic in Agile: Techniques for Collecting Epics
There are a number of approaches 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 approaches are described below.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Define Epic in Agile: Interviews
Interviews tend to be the default technique used to collect user story requirements. However, while this is one of the more common approaches, 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.
Define Epic in Agile: 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.
Prev <— Continue Reading —> Next
Learn More: Agile Daily Stand-Up
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
The Daily Stand-Up Meeting
A 59 Seconds Agile Infographic
