What level of detail should I include in epics?

Question

I am writing user stories for a new project. One of my epics is:

As a company owner I want a graphical profile so I can build my visual identity.

And then there are multiple user stories linked to this epic for creating a color palette, designing a logo and so on. But I am not sure what kind of details I should add for the epic itself. What should I write in the description of it? Should the epic have acceptance criteria?

One demand is that all graphical elements are vectors; should that be an acceptance criteria for the epic? Or should it be duplicated for all user stories belonging to that epic?

Answer 1

To me an Epic is a large User Story, every time a requirement comes to our team and it seems very large (e.g. > 13SP), we consider calling it an Epic instead of a Story. A good metric is: Does it fit into one sprint? But as the requirement is complete in itself, simply breaking it into smaller Stories, would lose the context. So you might say an Epic is a Story, or better call it a container, including several other Stories.

Atlassian describes it this way (1):

An epic is a large body of work that can be broken down into a number of smaller stories. For example, performance-related work in a release. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs.

An Epic should be less technical and more focused on the customers value compared to Stories (which should also have these element of course). Try to give your developers as much use-case information as possible. An Epic is more like a vision, the stories and tasks are the things to get there.

You decide if you need acceptance criteria for your Epic and which details are important to get the whole Epic done. In your case, it might make sense to add the vector thing and it should always be considered when testing a Story. All the Stories together must meet the requirements of your Epic.

Maybe this answers are also interesting:

• Relationship between user story, feature, and epic?
• What is the weighting difference between Epic/Story/Task

Talking about JIRA: creating an Epic has some nice support in JIRA and helps you planning on a high level than it would be possible with several stories (p.e. Viewing the Epic Report)

Answer 2

What is going to change when you have a visual identity? How do you measure success?

Delivering business goals, not just software features

https://www.impactmapping.org/delivering.html

The epic should be about the business goal, not about what you are going to build to achieve this goal. It should explain the why and how you are going to measure the goal is reached. The implementation details are part of the user-stories.

When can you stop implementing stories under the epic? Do you really need to complete all of them? I think user-stories are deliverable options to reach the goal, maybe the first story delivers enough value already. Now you can stop building the options and focus on the next epic.

I like how impact mapping helps you think in measurable goals and not in deliverables.

So to answer your question: Epics should contain measurables goals, not implementation details and or options to achieve this. Certainly it should not contain duplicate information.. The epic is the mission the team is on, it is the why. Where the user-story is the what.

In the ideal world the team can now decide by themselves how to best achieve this goal. Pro-active self-organizing people give the best results, certainly for creative processes like software development or designs.

Answer 3

Short answer:

There's no universally accepted definition of an Epic, so do what works for your team. They're smart people, ask them instead of strangers on the internet.

---

Somewhat controversial answer:

I've found epics to be most effective when they state a business objective and the metrics that will be used to determine that success.

Ex:

Increase click through rate on our home page by 15%

Notice how there's no sign of a feature or story to be implemented in sight? There's only a valuable business objective. This leaves your team constraint free to brain storm ways they might achieve that goal for you. Each experiment generated can be tried and validated against this goal. The Epic is done when the team has achieved the goal, or have gotten close enough that the P.O. decides it's good enough and has other more important work for the team to do.

Answer 4

As others pointed out, there is no universal definition of an Epic, so the following is based on my work experience.

What not to do with an Epic

In my practice an Epic can never be added directly to a sprint.

It is too broad, and a complexity based estimate would be way to inaccurate to even have a chance of knowing if it would fit into one sprint.

It usually covers several User Stories, each of which need to be estimated and prioritized independently - not only against other stories as part of this Epic, but against other stories (from other epics).

Just because the Epic is important, doesn't mean every story in the Epic is equally important. In reality maybe not all stories thought of as part of an Epic will even ever make it into the project, if other priorities come up.

For the same reason it is not wise to go into too much detail for individual stories, as at the point of drafting the Epic it is not clear yet which story will make it (when) into a sprint and thus into the product.

What to do with an Epic

Similar to a Story an Epic should justify its existence in the Backlog, by explaining:

• Why we want this in our product?
• Who will it benefit?
• How can we measure its success?

As an Epic might involve more then one User Role, potentially even more then one interface. Consequently it is in its nature to be too complex for writing it down as one linear Story.

It ultimately has to be broken down into several user stories, as only well encapsulated user stories should make it into a sprint.

Thus my favorite way of outlining an Epic is too write the epic as a drafted list of User Stories, without going into too much detail for each story.

For example:

• As a company Owner I can upload my existing logo
• As a company Owner I can define an arbitrary set of primary colors
• ...

When preparing for a next sprint and it's time to tackle the epic, User Stories can be broken out and specified in the agreed upon detail, prioritized and estimated for the sprint, and or left for the next sprint if the (expected) velocity is not sufficient to tackle all stories at once.

Answer 5

In my personal experience, best Epic is the one that communicates nothing more than a broad message of what it is about. A good epic should not have any scope of making an assumption neither should it sound vague to someone who has just joined the project.

When making an epic, I try to keep away from numbers and deliverable. During the planning my ideal epic would invite as much discussion possible within the team which would then be documented in stories. If all the stories are completed with their expected criteria, the Epic has efficiently done its job.