We are using Jira for our projects.
Standard hierarchy is Epic -> Story/Task -> SubTask.

We would like to have deeper hierarchy. Atlassian is suggesting (link) Theme -> Initiative -> Epic ... We would like to use generic names (Purpose, Vision or Strategy could indicate different meaning).

Is there any standardized hierarchy naming in the world ?

I was thinking Objective > Theme > Epic > ....

The reason is, that sometimes Epic is actually too small for feature. We would like to plan our roadmap for longer time frames.

  • Does that longer term plan need to be in jira? Oct 4, 2023 at 10:33
  • For the sake of this question, Yes. We need that in JIRA, for longterm scope and capacity planning. Oct 4, 2023 at 11:53
  • 1
    What is the purpose of this deeper hierarchy? What do you hope to achieve? Consider that Jira, ultimately, is a tool to create and track work as it moves through a workflow. Are you able to define states and workflows for these higher levels in the hierarchy? Or are they more like guiding principles that you use to order the other work items?
    – Thomas Owens
    Oct 4, 2023 at 11:56
  • 2
    Frame challenge: That article says "something ambitious, like launch a rocket into space" and "initiatives are often completed in multiple quarters to a year" and you want to add two levels and measure/track them (why else put them in Jira)? As Thomas' comment already suggested, can you make a real case for doing that other than 'for the sake of this question'. I'm not convinced if you write that "Epic is too small for feature" - is feature a mistype here?
    – Jan Doggen
    Oct 4, 2023 at 15:59
  • A theme is a set of related backlog items that are related. That's not the same as an epic, and misusing the term will confuse people.
    – Todd A. Jacobs
    Oct 5, 2023 at 2:06

3 Answers 3



In terms of user stories as a framework tool, there is no formalism beyond Epics -> User Stories -> Tasks with "themes" really just a form of collation that could possibly be applied at multiple levels. Features can be produced by any completed increment at any level that produces a coherent something, but are probably most associated with epics or user stories.

You can create your own hierarchy, but please don't. It works against core agile principles such as embracing change and just-in-time (JIT) planning.


Epics and themes are terms of art that originated with the XP movement and popularized by various books on user stories, especially those by Mike Cohn such as User Stories Applied (Cohn, M. 2004.)

Pragmatically speaking—you can look up definitions yourself if interested in formalisms—a user story is intended to be a cross-functional slice of functionality that is:

  • commonly written in the Connextra format, although there are certainly other formats;
  • meets INVEST criteria; and
  • is intended to be used as a conversation placeholder (not a formal specification) for the team and its stakeholders.

The difference between user stories and epics is generally that user stories should generally be decomposed until they can be completed within a single iteration, e.g. a single Scrum Sprint or the typical cycle time of the Kanban Method. Epics are generally just larger stories that won't fit into a single iteration. Epics are generally used to articulate longer-term or less-detailed objectives that should eventually be decomposed into smaller user stories that can fit within a single iteration.

Themes are groups of related stories. One supposes you could extend the idea to features and epics, but most practitioners would not understand the term that way. For ease of professional communication, a theme is just a way to bucket-sort related stories.

Because most agile frameworks are intended to be incremental and/or iterative, the utility value in having deep hierarchies is unclear. Unlike big, upfront development (BUFD) frameworks, agile frameworks generally value just-in-time and just-enough planning, so having some deeply-nested, project-specific naming convention with arbitrary names such as:

Magnum Opus -> Series -> Book -> Chapter -> Scene

would largely fail to communicate anything of value outside of a project unless the product is a literary work. Such labels are more likely to create additional overhead and cognitive burden, carry unnecessary layers of relational information beyond what agile frameworks generally consider necessary, and often encourage BUFD practices. Creating unusual hierarchies is therefore typically discouraged without a clear business use case.

Advice on Coining Project-Specific Terms

Unless you have a clear business need, just don't do this. In most cases, it's simply not needed. In addition, such naming conventions won't serve a useful purpose in communicating status or categorization as a form of professional shorthand, especially outside of the project where the non-standard terms are used.

If you do have a legitimate reason for doing this in your particular problem domain, then I would strongly suggest creating a project glossary with both standardized definitions and guidance for how your organization, project, and team should use the terms. That way, whether or not such terms are used elsewhere you can use them internally, consistently, and (if you share the glossary) in a way that will facilitate rather than hamper communication with stakeholders.


Is there any standardized hierarchy naming in the world

I have been around a lot of organisations and I haven't seen any standard practices in this. Everyone has their own way to do it that suits their domain, their organisation structure and the personal preferences of the people involved.

I would recommend using inspect and adapt. Try something, then evaluate it after some time has passed and adjust if necessary.


Have not seen standard practice. Our local practice uses Saga as parent of an Epic, and I think Opus as parent of Saga.

Our rationale was to stick to the literary theme evoked by "epic" as a means of indicating "this is a bigger bucket that holds smaller buckets".

Our use cases include a need to trace from business driver level through affected systems and subsystems down to affected components, each supported by a single team, so the work can be coordinated across the org.

We also allow single teams to use Sagas if they need to group a bunch of epics together, which I've had a need for sometimes.

  • Thank you, this makes also sense ! Oct 17, 2023 at 15:17

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.