Product Owners employ User Stories as product backlog items. User Stories represent requirements and are detailed during the course of the project. Large User Stories are called Epics. Epics are coarse grained User Stories and are usually decomposed during the project and detailed further on. And then there are Themes …
Often Themes are not used properly by some teams. I have seen that a Theme is either a more fine grained concept than an Epic or a more coarse grained concept and contains multiple Epics. It may not be wrong to use the concept of a Theme this way, because neither an Epic nor a Theme is clearly defined. But this confuses the team members and it is not helping us to adopt agile planning.
Clarifying the three different concepts before you work with them will help:
- A User Story represents a requirement and is small enough to be implemented by a team within one Sprint.
- An Epic is a larger User Story and represents a requirement as well, but it is too large to be implemented in one Sprint.
- A Theme is a set of User Stories or Epics. A Theme can reference multiple User Stories from even different Epics.
But for what are we using the concepts?
A User Story is a requirement that is digested by the team within one Sprint. A lot have been written about how to use user stories. Some teams avoid the concept of Epic and simply call them large User Story – fair enough. But it makes sense to call a large User Story an Epic, because the sizing of a User Story is an imported information. Having Epics in the Product Backlog indicates that the items have to be split. If in the Backlog Grooming meeting the team labels the backlog items as Epics, which means they cannot be estimated. Separating the large and small user stories with different terms, forces the team and Product Owner to make the backlog items smaller, which is a decent goal.
But Themes? Why do I need the concept of a Theme? The answer is: For roadmap and release planning.
Usually customers and users want to have many many features. It’s not agile and not helpful for the customer to convert all their wishes into fine grained User Stories, so they can be implemented by a team. It’s better to narrow down the desired scope and to get closer to the best business value for available team capacity with agile planning techniques.
Agile planning has many different levels. The highest level is the product vision, that describes the actual business goal of a project or product. The next level is the release roadmap. In this roadmap the product owner and the team agree on a series of releases with a rough scope – the Themes. Releases have Themes that describe the scope of the release. Within a release we usually want to build and deliver a Minimum Viable Product (or Minimal Marketable Feature). That’s a single or set of features that bring value to the customer. In the roadmap planning we want to find out which Epics and User Stories are a minimal necessary valuable set of functionality. Since Themes are a set of User Stories they can help us to find and describe the MVP.
How can I identify Themes?