Endless epics
Hi!
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?
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.
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?
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