What is an Epic in Agile Software Development?

Most people involved in Agile Software Development are familiar with User Stories which, in it’s slimmest form, consist of a narrative and a small set of acceptance criteria. But what about Epics? What exactly is an epic and how does it distinguish from a user story, theme, initiate, spike or task? Let’s have a look what the purpose of an epic is and what it usually looks like in Agile Software Development.

What is an Epic?

An epic as an rough outline of a feature or functionality. With that an epic usually is the first derivate from a product vision and will be further refined into user stories, which then can be broken down into tasks and turned into a product increment. Apart from what an epic is and how it should be used, I’ve often experienced the usage of the word ‘epic’ as a substitute for container or basket as a collection of (sometimes related) tasks and user stories. Thats possible but could also be achieved using labels.

Value of an Epic

The full power of working with epic in my eyes lies in what I’ve mentioned above, breaking a product vision into specific features or functionality. An epic may also have non-functional requirements or constraints attached to it, as far as know at this early stage in product development. Once an epic is a semantically meaningful piece of your product vision, it will serve you as a compass navigating to completion of the product increment. An epic helps you to keep focus, create goals for iterations and determine when the desired functionality is achieved.

What should an Epic contain

Basically an epic should outline a feature or functionality and the value of it. With that it can also be a place holder for more specific user stories or just capture an idea in first place. In a further refined state you should add what needs to be implemented so that an epic is achieved. All modifications to an epic should be validated against your product vision in order to achieve it and to avoid drifting apart. Once the epic becomes clearer you could add remarks or outline potential user stories before actually splitting your epic into such. Additional an epic may contain constraints or non-functional requirements, such as performance requirements.

How to continue?

After your epic has a certain maturity, it will smooth to break it down into user stories. During this activity, your epic help you to keep focus, ensure your user stories contribute to achieving the epic and with that stay in line with your product vision.