Epic

I define an epic as a large, coarse-grained requirement in agile development. For example, I treat “Account management” as an epic. It groups multiple user stories. For instance, I include “View account balance”, “Open account”, and “Close account” under that epic. Therefore, I plan work at a high level first. Then, I break the epic into smaller stories for an iteration.

I focus epics on stakeholder needs. Thus, I link each epic to value for the users or the business. Furthermore, I use an epic value statement to describe who benefits and why. In addition, I use that statement to help prioritize work. Consequently, I decide which epics and stories the team tackles first.

I store epics in the product backlog. Also, I treat them as placeholders for future refinement. Since an epic is too large for one iteration, I split it into features or stories. Next, I refine those items until the team can implement them within one iteration. Some tools call all items backlog items and let me refine them until they are small enough.

I use story maps to present epics and stories visually. For example, I lay out business activities horizontally. Then, I place related stories under each activity. This approach helps me find the walking skeleton. In addition, I identify the minimum set of functionality that delivers a working business process. As a result, I deliver value early and often.

I apply epics during iteration planning and prioritization. First, I evaluate the benefits of an epic. Then, I compare epics using value and cost. Moreover, I consider dependencies and risks. Consequently, I sequence work to maximize product value. Finally, I break high-priority epics into implementable stories for the next sprints.

I keep epic descriptions simple. For translation and clarity, I use short sentences. Also, I avoid technical jargon when possible. Because epics aim to express stakeholder needs, I write them from a user or business perspective. Thus, other stakeholders can easily understand and translate them.

I recognize that scaling agile to large and distributed teams remains active work. However, many frameworks and tools support multiple requirement levels. For example, I may use the levels epic, feature, and story. Alternatively, I may use only backlog items and refine them. In any case, I maintain a clear hierarchy. In addition, I record acceptance criteria and success measures as I refine the epic.

I recommend that you treat epics as living artifacts. Therefore, I revisit and adjust them as the product evolves. Meanwhile, I keep the focus on delivering value. As a result, epics help me manage complexity and plan releases in a clear, traceable way.