Can an Epic span multiple versions / releases?

Question

Is an Epic, containing multiple User Stories, allowed to span more than one version or release?

Answer 1

TL;DR

Yes. There is no issue with this at all.

Discussion Points

The concept of Epics are pretty amorphous and undefined. You can find descriptions of Epics as large user stories that need broken down and in that regard, it is common for some to try and squeeze them into a release train window.

For instance an Epic may be a container for a specific measurable outcome

Implement the Mastercard API

Which is then comprised of multiple or even dozens of user stories.

Personally, my teams have always treated Epics as containers for things of a similar nature. For instance

AWS IAM Security 

In this regard, we might deploy some stories in Release 1 and add additional functionality or patches or upgrades in 3 or 10 or 20 releases from now. So the Epic is never done. If you take this approach then the Epic is never done because it is just used to group functionality.

Other teams use the Epic field to represent an entire feature or mini project on a scaled board showing other features or projects. This view is akin to a roadmap stored on a kanban board in your ticket tracker. So while the Epic will be marked as Done eventually, it will certainly not be within a single release.

Why is There a Divergence in the Force?

The truth is, the Epic field became divorced from the original idea of an Epic when Jira became the industry standard tool for tracking and visualising work in an Agile environment. Prior to that, most Agile practitioners had a fairly standard view of Epics.

The reason for the evolution is that Epics were aligned to Themes as a concept and Jira did not originally allow teams to track Themes.

So in time, the Epics field then became used for anything that teams really needed that was slightly large, whether it be a series of user stories, a complete scope for a feature or to represent work in a project or anything else.

Themes as a concept really died out and very few people ever refer to Themes as an idea. Some teams still use Themes and several PMSE posters could give you case studies I am certain but the majority of organisations have never been exposed to Themes and Epics.

Golden Rule

If you are in doubt, return to the golden rule.

The primary measure of progress is working software

So set up your Epics and use them in a way that supports transparency and ease of communications in your team. Organisational thinking always evolves so do what works for your team as long as you are not covering up an anti-pattern.

Don't be forced into the idea some things have to be released in a certain way to be agile.

Note

Will add in 4-5 hyperlinked references when I get back from my daily stand-up

Answer 2

"Allowed" by who/what?

Allowed by Scrum? Yes.

Scrum is a framework, entirely encompassed by the Scrum Guide. There is avast array of processes that Scrum does not prescribe, assuming/allowing/forcing individual Teams to figure them out for themselves. This is one of them.

Allowed by Kanban? Yes.

Kanban is even less prescriptive than Scrum. Kanban is just a way of visualizing work plus the concept of Work In Progress limits.

Allowed by your boss/team/company? Ask them, not us.

Every company will have its own situation and standards, for its own reasons - sometimes sensical, sometimes not. When in doubt, just ask.

"Allowed" by common sense/practicality? Yes.

Sure, there's no obvious reason why you can't use Epics to span multiple releases. See Venture2099's answer for more in-depth.

Answer 3

There are no rules, so yes! But this is a question to ask your team(s). If they want to do so, go for it. If not, don't.

Answer 4

In my opinion – driven here mostly as a well-seasoned software developer, I would recommend that you subdivide your "epic" to consider both releases and (especially!) versions separately. And here's why: the underlying source-code might be possibly-substantially(!) different. Therefore, I would "ask the team(!) what really makes the most sense."

Software developers have a well-defined "version control" strategy which allows them to manage both releases and versions in parallel. Therefore, they should be able to tell you whether the various so-called "branches" that you are considering for your epic actually belong together.