As I set out to put together a guide to product backlogs, I kept running into the nagging feeling that I needed to be very clear about how I used certain terms.
Namely, I wanted to make sure I was using the terms epics and features consistently.
Now you probably do not lie awake at night with the same nagging concerns.
Maybe you should.
Ok, probably not lie awake at night, but at least be concerned about it enough to make sure that you and your team have a shared understanding when it comes to the structure of your product backlog.
If nothing else, it may prevent some soul sucking arguments about whether a product backlog item is an epic or a feature.
So this week I set out to define key terms used in product backlogs, namely themes, epics, features, and user stories and how I use them in the product backlogs I work with. The link to that post, and other posts providing different, sometimes conflicting, perspectives are below.
There is a difference between epics and features and it does matter. Unfortunately, the nature of that difference depends on how you chose to structure your product backlog.
Themes vs Epics vs Features vs User Stories
Here’s an epic (pun intended) post exploring what the terms theme, epic, feature, and user stories mean when it comes to product backlogs, how I prefer to use those terms, and some things to consider when you setup your product backlog.
Atlassian’s views on epics, stories, themes and initiatives
If you sell software that helps teams manage their product backlog, you’ll most likely need to establish a preferred scheme for categorizing those product backlog items. Max Rehkopf describes how Atlassian views epics, stories, themes, and initiatives, and how to use those concepts in Jira. I include this not as an endorsement of Jira so much as an example of how some teams view these types of product backlog items.
Agile Alliance Glossary item on epics
An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.
Agile Alliance glossary item on user stories
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.”
Each user story is expected to yield, once implemented, a contribution to the value of the overall product, irrespective of the order of implementation; these and other assumptions as to the nature of user stories are captured by the INVEST formula.
Feature Driven Development
Feature Driven Development (FDD) is probably the first agile framework that was intended for use by large teams, predating scaled agile models by over a decade. The framework never saw much adoption, however some aspects have hung on. Including (ironically) the definition of feature used in the framework which differs than that used by other frameworks. Mike Cohn has suggested that features as used in FDD make a good format for product backlog items that are more technical in nature.