When should items no longer be added to an epic?
Say we have a product feature for user profile management which is considered an epic. Under this epic are 10 user stories.
When we have new user stories / tasks related to this epic, how long is too long, to keep adding to the epic?
Let's say, for example, the 10 user stories were completed, the epic is closed. Three months later, following user feedback, we need to enhance the user profile management. Do we add to the existing - but now closed/completed - epic, or do we create a new epic? (User profile management 2?)
This is still part of the same parent feature for user profile management so it doesn't belong on it's own or part of anything else. Epics can't live forever (or can they, should they?) and it doesn't seem sensible to append numbers to epics or have clashing names. While the feature is not complete we are fine with adding more but this can lead to an always shifting deadline so the epic never closes.
I'm interested to hear how this should be approached.
An epic user story is still a user story, meaning it is a placeholder for a conversation about a possible requirement. When the conversations are over the story is over. If more conversations are needed, then that would indicate a new story or epic.
The Scrum answer to this is "what's an epic?". The Scrum Guide does not say anything about epics, stories, tasks, etc. That is a construct that your organization has decided to use. This comes from the Scrum Guide's section on the Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Epics are a method that many people use to help associate Product Backlog Items together in some meaningful way. Your Scrum Team needs to be the ones that answer your question.
However, my suggestion is very much in line with @Ian Mitchell's response. Every Product Backlog Item describes a change that needs to occur to the product. In your explanation you state that the original change has been completed and that a new change is being requested. So in my opinion, the two are only related because of the code base. But if you have a need to keep track of all changes made for the user profile management in an easy to navigate way, you might want to keep them associated to a single epic.
Again, it is all up to your team to decide.
Thanks for the responses. Having the conversation and up to the team to decide how it works for us is great.
I noticed a post from Garrie Irons that resonates:
"Epics give "arcs of activity." That's all. So you may have a "make it usable" as your first epic, and "make it mobile" as your second, then "beyond the MVP" as your third (by which point, you may have defined some new Epics). Every iteration is workable - the Epics put the Iterations between bookmarks describing "what did this set of sprints do?"."
It might be worth considering creating a new Epic and linking it to the first one if you have a tool that provides for that.