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?
2
-
2It depends. Why are you estimating in the first place?– SarovCommented Mar 12, 2020 at 15:54
-
1We size in order to understand complexity. We keep track of sizing to understand average velocity. My gut is telling me to ignore Epics in tracking and estimation, and to focus only on the constituents of the Epics, since that is the work that will be performed.– Mark SalutaCommented Mar 12, 2020 at 16:01
Add a comment
|
5 Answers
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.
-
3There are some good points about perspectives here, but this is a non-standard usage of the term "epic" in my experience. Commented Mar 13, 2020 at 15:56
-
4This doesn't seem to address the question, which is about whether epics should be estimated or not. I think your unconventional interpretation of "epic" might be confusing matters. The commonly used definition of epic explicitly is that it's a very large user story. Commented Mar 13, 2020 at 18:22
-
Vicki, I'll accept and acknowledge that my use of the word "epic" is a non-standard usage of the term, because I express the opinion that "the story-telling metaphor does not quite fit." The literal human term is that "an epic is [just ...] a big story," and I don't think so. Ruaidhri, I'll answer your question by saying that I think that epics are estimated but in a different way. I think that your estimating needs to consider both perspectives at once. While you are estimating "story = unit-of-work," simultaneously estimate "epic = context." Commented Mar 16, 2020 at 15:42
-
2This question has been flagged by members of the community as "not an answer." Please update it to explain how this relates to the OPs question about whether or not to assign estimates to it, or it may be closed/deleted/downvoted by the community.– Todd A. Jacobs ♦Commented Mar 16, 2020 at 22:32