Skip to main content

Endless epics

Last post 03:21 pm March 14, 2023 by David Garcia Sanmarti
3 replies
10:48 am March 13, 2023


I'm a bit confused, in the scrum teams we have some epics for different amount of stories talking about the same topic. Otherwise, due iterations appears stories ( little stories) that complete functionalities or change services. 

The trouble is, this stories are not talking about specific epic BUT we can add into one if we take context of each one, the problem of this "solution" is that we create an "epic" that never ends...

Our epics have a delimited effort and functionality to deliver. I think about Components but I've not sure if create components in parallel of Epics is a very good practice to maintan and have the backlog classified.

In out experience what would be the best troubleshoot for that?

03:17 pm March 13, 2023

With the teams I have worked that used Epics and User Stories, the Epics were really nothing more than a way to group like User Stories for managing the Product Backlog.  We often had Epics that never ended. For example, many of the teams had an Epic for technical debt.  By associating User Stories to Epics, it helps to convey information on why the items exist in the Product Backlog.  

The first mention I know of for epics was in a book written by Mike Cohen on how to use User Stories in agile development.  If I recall correctly, and I'm paraphrasing, he said that large stories that need more definition are called epics.  They are usually at the bottom of the backlog and as they move up, they are refined down into smaller and easier implemented story sizes. 

The real problem with Epics is that everyone uses them differently.  Scaled Agile Framework (SAFe) has their own definition of an Epic and in fact, they prescribe a backlog made up entirely of Epics. 

While we can all give examples, like I did at the beginning of my response, in reality only your team can decide how Epics benefit them. If what they are doing now helps them, then why would it need to change?  The Scrum Guide says nothing about how to manage the Product and Sprint Backlogs.  The terms "user story(ies)" and "epics" do not appear in the Guide.  But it does state that the Product Owner is accountable for managing the Product Backlog and that the Scrum Master is accountable for helping the Product Owner come up with ways to effectively manage. But in the end, what ever methods/processes are used should be something that the respective Scrum Team agrees is best.

06:59 pm March 13, 2023

the problem of this "solution" is that we create an "epic" that never ends...

Scrum is about learning to build the right thing at the right time. For as long as the Product exists, a Product Backlog will also exist, and it will always be an emergent body of work. With that in mind, why would you expect an epic to have an end?

03:21 pm March 14, 2023

Thanks for the quickly responses.

We need an "time boxed" epics because que have a Roadmap which show to our stakeholders the main threads we are working in a determined period, but we have an epic that always keeps growing so is useless to show a full period epic which expand over and over plannifications

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.