If we have a User Story that is determined to be an Epic, and we vertically slice the functionality into its logical parts and estimate the resulting User Stories and Tasks, is it best practice to only estimate the slices, and put a zero estimate on the Epic so as to not interfere with reporting?
An epic is generally considered as a coherent piece of work that is either a) too big to fit in a sprint, or b) too big to estimate.
An epic is not a product backlog item (PBI). The work items that comprise it are PBIs.
It's only the PBIs that need to be estimated.
Thus, your intuition is correct. Typically, an epic is simply a container for smaller items, and there is no need to estimate the epic itself.
Some ticketing tools may helpfully sum the estimates of the epic's contents to give you an overall estimate for the epic, which should not be treated as accurate of course but as a ballpark and as something you can use to burndown the epic.
It probably also depends on what you use epics for. Do you use them to track portfolio development efforts, or just as a container for user stories?
Also, it is not entirely clear what role you are playing in this team. If you are a team member or Scrum Master - as I suspect - then it's most probably enough to focus on user stories and leave epics as they are (given you are not explicitly requested to point them).
Do you gain any benefit from aggregating story points at Epic level? If you don't leave it, if you do, point them.
It depends on why you're estimating in the first place.
We size in order to understand complexity. We keep track of sizing to understand average velocity.
I would posit neither of those reasons matter to Epics. Thus, if you estimate Epics, you're just estimating for the sake of estimating, which is pointless.
Always try to understand not only what to do, but why you're doing it. When you do, it becomes straightforward to decide how to modify.
I would not estimate an epic, only the underlying stories. This because you would have to recalculate everytime an estimate for underlying stories changes, is added or removed. And that is exactly what should happen with an epic. New insights will change the underlying stories.
Scoping the epic correctly seems more important to me. For example an epic called technical debt with the description in the line of "we need to remove all technical debt" will never be finished.
If you scope the epic to a certain part of the application or to upgrading a certain framework, the epic and underlying user stories make more sense. This might be a bit off topic, but I hope it helps
To my way of thinking, "Epic" is the name given to an overall project, while "user story" is given to a more bite-sized part of it. While I'm not particularly a fan of either term, I think that "epic" is more misleading because it implies what the term means in real life: "an epic is simply a larger story." I don't agree. I look upon them as viewpoints.
To me, "Epic-level" thinking should be considering the project as a whole, while "Story-level" thinking parses the project into individually-schedulable units of work. So, if you perceive that "a story has become an epic," then "it always was epic." Look carefully to find more such epics. Then consolidate these into "one actual epic." Into one over-arching definition of "the project as a whole" which will help you to better lay-out and schedule the stories.
"Epic-level thinking" is where you're concerned about things like dependencies. Where you're looking at where the "stories" that the "users" are telling have something in common. It's also where you're on the lookout for cases where "one individual user-story, unbeknownst to that user, doesn't tell the entire story." I think that you always need to be simultaneously looking from both perspectives, all the time.
Paying close attention to the "epic" point-of-view while laying out "stories" will help you to ensure that these are the right stories. That they are complete stories. That you've assembled the right story-tellers together to enable you to devise a good, actionable piece of work to do next.
Epic is the forest; user-stories are the trees. Each have their proper place, and you need to be concerned with both at once. And IMHO the "story-telling metaphor" does not quite fit.