Agile teams typically differentiate between “epics” and “user stories.” In most cases epics are just really large stories that sit far down on your product backlog until the team is ready to flesh them out into more detail.  The logical question is how to scope an epic and then break it up into user stories within agile.

There are a host of activities that happen between a semi-defined need (i.e. an epic) and a list of defined requirements to be built (i.e. the user stories). The goal in creating an epic to scope out a feature or a project to get just enough clarity around the what and the why and dig into just enough of the how to create a common understanding of what will be achieved with a given set of work. An epic is a great way to keep track of the big picture in agile environments.

With that context, here are the sections of the epic template I use:

• A one sentence description of the feature, written in the syntax of a user story “As a [user] I can [do something] to [achieve some benefit]. This is probably the “epic” on your product backlog.
• Benefits. A list of the specific benefits to be achieved via the implementation of the feature. The goal is to answer the question of, “why bother?”
• Scenarios. If your feature supports more than one business process scenario, this is a good section to include.  Capturing the scenarios keeps the requirements process aligned with how people will actually be using the new software.
• Features list. Identify the features that are included in the “scope” of the epic. These can be written in the user story syntax as well and might logically become the product backlog items or the be broken up into multiple user stories.
• Existing functionality to integrate. Often you’ll be building a new feature on top of some existing functionality.  Overlooking the current capabilities the software needs to continue to fulfill is a common requirements oversight I want to avoid.
• Assumptions. A list of things you’ve assumed to be true that were validated (or invalidated in some cases) by the business stakeholders.
• Nice to have features.  More of the above, but these will result in lower priority or non-existent product backlog items.
• Out of scope. Especially if you come from a traditional background, it’s difficult to resist including this beloved section for what you’re not doing. And it can help keep your team on track in terms of delivering what absolutely is needed to create value. Without this section, otherwise out-of-scope items might creep into your product backlog and divert your team’s focus from delivering on the value proposition.

All of the above looks a lot like a typical requirements document. The difference is it defines the scope around one feature (not an entire project) and, although you might need to succumb t small margins and minimal formatting, you can fit the information onto a single page.   It’s more agile than traditional approaches in that we’re not scoping a huge project and then diving in.

>> Learn More About Agile Requirements

Check out the Agile Track of Crafting Better Requirements, a virtual, instructor-led course that will also earn you 21 PDs or CDUs. You’ll learn about how to create a product backlog, turn stakeholder needs and wants into user stories, and create acceptance criteria to support testing.

Click here to learn more about Crafting Better Requirements – Agile Track