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?

  • 3
    At heart, an epic is a really large story. This doesn't read like an INVEST story. Perhaps start by rewriting the epic to have a more measurable value proposition: "As a company owner, I want a graphical profile to build my visual identity so that..."
    – Todd A. Jacobs
    Commented Jun 26, 2017 at 21:48
  • @CodeGnome Yeah, that sounds like a good idea and it is what I started doing.
    – Andreas
    Commented Jun 29, 2017 at 22:32
  • @Andreas you have 5 answers now, please consider accepting one of them and show others, your problem is solved. If not, you may give more details on what's missing.
    – ppasler
    Commented Jul 2, 2017 at 12:14

5 Answers 5


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:

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)


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

Delivering business goals, not just software features


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.

  • But user stories linked to the epic is not about the methods you are going to implement to achieve the goal either. This does not answer my questions.
    – Andreas
    Commented Jun 26, 2017 at 17:08
  • I think it does answer your question as the Epic is the WHY and the userstory is the WHAT. This clearly differs them and what information should go into them. To remove some confusion I changed the word methods to what. It is not about programming methods, but methods are words that describe in detail how it should be done it is a counter word for results which describes the higher goal.. Commented Jun 27, 2017 at 7:24
  • @NielsvanReijmersdal I disagree with Epic == Why, Story == What. A Story should also include the Why part, What (technically) are the subtasks of the Story. To me an Epic is more or less a container including several Stories.
    – ppasler
    Commented Jun 27, 2017 at 8:13
  • 1
    @ppasler I agree with you. Certainly stories without an Epic should also explain their value and why clearly. I need to think about this more and how to make sure I explain my thoughts. Commented Jun 27, 2017 at 8:52
  • I also don't think an Epic is per definition a 'Why' - however the bigger the change to the product the higher the need to focus on the 'Why' at first. Commented Jun 27, 2017 at 11:53

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.


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.

  • Interesting thoughts. For your example your definition is fine, but OP one's different and it has not this level of abstraction.
    – ppasler
    Commented Jun 27, 2017 at 11:16

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.