a large body of work that can be broken down into a number of smaller stories, or sometimes called “Issues” in Jira. Epics often encompass multiple teams, on multiple projects, and can even be tracked on multiple boards.
Epics are almost always delivered over a set of sprints. As a team learns more about an epic through development and customer feedback, user stories will be added and removed as necessary. That’s the key with agile epics: Scope is flexible, based on customer feedback and team cadence.
An epic should give the development team everything they need to be successful. From a practical perspective, it’s the top-tier of their work hierarchy. However, understanding how an epic relates to other agile structures provides important context for the daily dev work.
A product roadmap is a plan of action for how a product or solution will evolve over time.
A theme is an organization goal that drive the creation of epics and initiatives.
The product roadmap is expressed and visualized as a set of initiatives plotted along a timeline.
Breaking initiatives into epics helps keep the team’s daily work — expressed in smaller stories — connected to overall business goals.
A set of completed epics drives a specific initiative, which keeps the overall product developing and evolving with market and customer demands on top of organizational themes.
When should an Epic be created?
Consider creating an epic if you have a large body of work that needs to be completed over several sprints or over a long period of time. You can also create an epic when you notice a pattern among several user stories, and you want to bundle them into one group.
Creating an Epic
When creating a new epic, consider other planning and organization tools your team may already have in place. Creating epics around a team’s quarterly goals or OKRs is a great start. When creating an epic, consider the following:
Reporting — Create epics for the projects that managers and executives will want to keep an eye on.
Storytelling — UUse epics, and the stories that roll up into them, as a mechanism to tell the story of how you arrived at the current state of a feature or product.
Culture — Let organizational culture dictate the size and granularity of an epic.
Time — Most development teams rely on estimation frameworks instead of time, but it’s a worthwhile gut check to make sure your epics will take a couple of weeks to complete. Not too long and not too short.
Example of an Epic:
There are different reasons and situations when an Epic should be created. When thinking about more complex work demands or trying to organize a group of related stories like the release of a product version, the creation of an internal campaign, and the launch of a new website. To launch a release or deliver a job, there is the need to organize work and Epics are meant to help manage work across teams.
It is important to have in mind that some fields in an Epic are required and important to fill:
Epic Name: where the reporter should define the body of work that needs to be done.
Summary: a brief description about the objective and context of the work.
Components: is a field that indicates the design team that will be responsible for the work.
Initiative: sometimes an Epic can be related or linked directly to a greater initiative.
Priority: how important or urgent the work is at that moment;
Assignee: the person who is going to be responsible for the work.
Reporter: the person who had the initiative to ask or is requesting the work.
Liferay Watchers: one or more stakeholders that will be informed over the Epic updates.
Description: a more detailed text giving important information over the work to be done.
Attachment: any imporant docuemnt should be attached to this issue
Linked Issues: if there is one or more issues that may have a direct impact over the Epic, then it can be listed here.
Labels: is a complementary way of organizing by topics or themes all the work that should be done.
Sprint: if the Epic is related to a team that works in running in sprints.