Theme, Epic, Story, Task

What is the difference between an epic and a theme? What is a story? Is a task testable in its own right? Can you work on an epic in a sprint?

The opening session of the London Agile Discussion Group (LADG) looked at these basic terms to see if there was an agreed understanding. We were all pretty close to an agreement, but there were some interesting ideas too. Here’s a summary of what we came up with (along with my examples):

Hierarchy of theme, epic, story and task

(aka Product Backlog Item, Work Item)

A story is an individual feature or requirement that the client (and business) wants. It is something that is deliverable (i.e. production ready) within a single sprint. A story should use the INVEST acronym (covered in this previous blog post).

However, it was also thought that a story is only a starting point for a discussion; it does not have all the information the team may need to complete the job.

Stories are often written in a specific format:

  • As a [end user of the required feature]
  • I want [actual thing the user wants to be able to do once the feature is live – so often contains a verb]
  • So that [why they want this feature / the benefit this feature brings]

Although this format has caught on and is commonplace, it is not the only approach. One team stressed that they alter the above format to put the “So that …” first. I think this is a smart idea as everything should be done for a valid business reason: starting with explaining the benefit certainly makes sense to me.

An example story: “As a customer, I want to be able to save a product in my wishlist so that I can view it again later.”


An epic is a big story. A requirement that is just too big to deliver in a single sprint. Epics need to be broken into smaller deliverables (stories). This helps them support the agile principles (e.g. delivering working software frequently, early continuous delivery, regular reflection).

An example epic: “As a customer, I want to be able to have wishlists so that I can come back to buy products later.”


A collection of stories by category. A basket or bucket of stories. By its nature, an epic can also be a theme in itself.

However, interestingly, one group thought that themes should refer to business goals. My view is that everything should have a goal (otherwise why are you doing it?!)

An example theme: “Wishlist”.


The elements of a story. Stepping stones to take the story to ‘Done’. Tasks often follow the SMART acronym: specific, measurable, achievable, relevant, time-boxed (although what the letters stand for seems to be hotly debated).

However, many teams don’t break their stories down into tasks. I have found that splitting stories into tasks encourages teams to split work horizontally, whereas we try to slice work vertically.

An example task: “Put ‘Add to wishlist’ button on each product page.”


The Innovation Revelation: A story about how to satisfy customer needs.

A real-world guide to taking a customer-focused approach to creating products and services that people actually want and are happy to pay for.

9 thoughts on “Theme, Epic, Story, Task”

    1. Personally, I’d say that the Product Backlog is a list of ALL items that have not yet been done, whereas a theme is a collection of epics/stories (within the product backlog) that relate to one another. Now, it might be that all the remaining items in the product backlog relate to the same theme, but that’s not always the case.

      What do you think?

  1. Thanks for this. These are controversial terms and this presents one clear definition of this heirarchy.

    One thought though…
    “As a customer, I want to be able to save a product in my wishlist, so that I can view it again later”

    Could one really say that this story is valuable? I agree it is independent, but cannot really see what value i would get by just saving a product in the wishlist – if i cannot then view it or interact with it in another way.

  2. Catherine Macintyre

    Hi there,

    I was wondering of these topics can be practically applied to a Kanban board as opposed to a scrum board? How do you visually represent Themes and Epics on a Kanban board?
    Surely themes and epics can’t feature in the WIP columns as they are made up of tasks/stories which would be the parts to move across the board? I’m just trying to get my head around Themes, Epics and Stories and how they would translate into a visual board or would they just sit above the board itself as broader goals?


    1. Hi Catherine. A Kanban Method work item would normally be something that gives some sort of new ability to a user, so it would normally be at the story level. If you wanted to identify which theme/epic a work item belongs to, maybe you could visualise that by colour-coding it (eg blue dot for wish list work items). I’d certainly not encourage teams to have work items at the task level because that does foster teamwork and doesn’t deliver any value to a user (eg having just the database layer built). Does that answer the question? Would that work for you?

  3. I find it helpful to compare scrum/kanban to traditional project management using work breakdown structure (wbs).

    Traditional wbs…
    – project: renovate kitchen
    – Phase: purchase new appliances
    – Workpackage: purchase new oven
    – Task: review ovens

    – Theme: renovate kitchen
    – epic: purchase appliances
    – user story: purchase new oven
    – task: review ovens

    Both have a lot in common…
    – A workpackage/user story is around 8hrs work (no more than 40hrs)
    – Traditional PM has weekly meetings…scrum, kanban has sprint review, or replenishing. Basically someone making sure everything is on track.

    Both have acceptance criteria (yes or no)…scrum has definition of done for a feature…traditional pm has success criteria for a deliverable.

    Basically the same, just wrapped up differently.

    I like to keep it simple…
    -What are we doing?
    -Why are we doing it?
    -How will we do it? The steps (to do column in kanban)
    -When is it due?
    Monitor weekly.

    Covers 99% of projects.

    Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.