Epics or Feature Groups?

One of the most frequently asked questions I get from new users of VersionOne is, “When should I use an Epic and when should I use a Feature Group (aka ‘Theme’)?” Either asset can be used for grouping information, so there’s a lot of flexibility in the application of each.  This flexibility has resulted in a lot of creative uses of Epics and Feature Groups, but it can sometimes create a bit of confusion.

How to most appropriately Epics or Feature Groups was also a question I had when I was a new VersionOne user.  Having worked through that question myself, and then having had the opportunity to work with many teams experiencing the same dilemma, I suggest making the distinction between Epics and Feature Groups in terms of two attributes: (1) Type of Information Represented and (2) Lifetime.

Type of Information Represented

Typically, an Epic is used to represent some specific capability that consists of smaller Backlog items which can be implemented independently.  The Epic can be viewed as a single capability by stakeholders, if that’s their preference, and it provides cohesion between those smaller, independent Backlog items that roll up into it.  For example, stakeholders might see “Manage Account” as a capability, and may be interested in tracking it at that level.  As the Product Owner and Team look at this in terms of how it can be implemented, however, they might break this down into smaller Backlog items such as “Create Account,” “Update Account,” “Archive Account,” “Generate Account Summary Report” and so on.

A Feature Group (or ‘Theme’), by comparison, usually represents a category of functionality, rather than some specific capability.  Using the example above, the first three Backlog items might be associated with the “Account Management” Feature Group. “Generate Account Summary Report” might be in the “Reporting” Feature Group:


If an Epic is being used to represent some specific capability, all of its constituent Backlog items will be completed at some point, so eventually we can close the Epic in VersionOne (the action taken to signify that we’re done and we’re moving on).  Meanwhile, the product lives on.  In other words, the lifetime of an Epic in VersionOne is typically shorter than the lifetime of the product.

A Feature Group’s lifetime is most often equal to the life of the product because it’s being used to define a category, rather than a specific capability.  A product’s “Account Management” Feature Group, for example, might be used to identify Backlog items pertaining to account management, and that Feature Group could then be used for filtering and reporting.  Throughout the life of the product, account management-related Backlog items will be completed and closed, and new ones created. But the “Account Management” Feature Group will remain alive as long as that category of functionality remains part of the product.

Another important note is that since the lifetime of a product will normally include many releases, and since an Epic’s constituent Backlog items may be implemented over a series of releases, both Feature Groups and Epics can span Projects in VersionOne.  The image above illustrates this.

Recapping then,

  • An Epic is typically used to represent a specific capability that’s comprised of smaller features which can be implemented independently, and its lifetime is shorter than the life of the product
  • A Feature Group is typically used to represent a category of capabilities, and its lifetime is usually equal to the life of the product

I use the word “typically” here because this is how organizations normally use these two assets.  Bear in mind though that Epics and Feature Groups are simply means of organizing information; you may find other uses for them as you continuously adapt the way you work for the better.

How are you using Epics and Feature Groups in your organization?

Lee Cunningham

About Lee Cunningham

Lee Cunningham is the senior director, enterprise agile strategy at VersionOne. Lee is focused on advising the executive sponsors and senior leaders of large enterprises, providing insight and practical guidance to meet the challenges of large-scale agile. Prior to joining VersionOne, Lee held numerous positions of leadership in software development and delivery. He grew the agile practices in several organizations, and led the agile transformation of a large multi-national enterprise. Lee has trained, coached, and mentored hundreds of teams in scores of organizations around the world. His experience, pragmatic approach, and customer focus keep him in demand as a trusted advisor.
This entry was posted in General, Product & Release Planning, Product Owner, Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *