Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

epic management in JIRA software

Prem Chudzinski _extensi_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 08, 2017

Hi everyone,


I'm trying to improve our boards and I'm lost with the concept of epics.

We support our software development. process using jira.


Our scenario:

1. We use kanban boards and the swimlanes are epic based.

2. Our epics represent product sections/parts

3. Tasks (Story, Bugs, CR) represent features whithin product sections

4. We don't use subtasks at the moment

5. We use components to group tasks as well

6. Statueses: Backlog->Selected->In Progress->ReadyTo Test->DocumentMe->Done

7. We use versions and releases



Epic: Product Built-In tutorial

Story\Task:  Tutorial for the admin page

Components: admin page, tutorials & help



  • We have to maintain two separate boards one for epic one for the stories
  • Epics can't be always included in the release as they are too generic and may be extended later on - that would require reopening. 
  • We had no epics at the beginning but it was hard to maintain board swimlanes which were created using JQL. I had around 50 entries which were component based - that was the reason we went for epics.
  • With no epics we'd have to use subtasks which have similar limitations - in this case our swimlanes would have to be Story Based and we'd endup with the same issue.




Any advice? 

I'm looking for some real life examples/use cases. 


Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 08, 2017

Most of that sounds ok, with the exception of point 2.  An Epic should not be a product section, it should be a (very large) story which has an eventual end. 

Moving on to your reported issues

  • I'm not sure why you need separate boards.  Even if you do, I'm not really certain why it should be a problem, as I often tell people to use many boards (Although I do say one Scrum board for planning across the team, and then as many Kanban as works)
  • Epics would not normally be included in a release.  You just close them when they've finished (all stories complete)
  • 50 Swimlanes is way too large, I agree.  I'd suggest looking at the boards instead, it sounds like they're trying to include too much
  • (last point is probably just a result of the first three, although I'm not sure what the actual limitation is)
Prem Chudzinski _extensi_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 09, 2017

Why epics should not represent a piece of the product?


Lets take a www as a product example:

Themes ->Something super big

Epics -> Admin Page, Login Page, Search Engine

Story->Delete users on admin page, Clear cache on Admin Page, integrate google engine in the search engine...

Components-> for stories only like user management, ect..

Regarding swimlanes: yes 50 swimlanes to represent "epics" was way too much thats why I use swimlanes by epics 

So the issue is that we do releases using stories but epics have to te tracked manually on a separate board.

Epic details on a board don't show included Stories/Tasks so its hard to tell which stories are included unless you open the ticket in a separate window.


Using the given www example how would you design the structure of the epics/story/components?

Sam Hall
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 09, 2017 • edited

Why epics should not represent a piece of the product?

A way to think about Epics is as representing a big chuck of work needed to make the product do something for a user (or set of users).

i.e. Epics represent (big) blocks of work required to build the product. They don't represent the product or pieces of the product itself.

Epics are exactly the same as stories, just larger.

A good Epic should have clear acceptance criteria and scope, just like a good story - a clear definition of what needs to be done for the work to be considered complete.

If you just have an Epic 'Admin Page', it's not enough. This doesn't tell us what the Epic is really trying to achieve. It could live forever as you decide to make more and more changes.

Instead, the Epic would be better defined as something more definite. To give a trivial example: 

"Core Admin Functions:
As an admin, I want an admin page allowing me to perform important stuff. As a minimum, to get the site live, I need to create, update and delete user details and clear the system cache so that everything runs smoothly."

This then breaks down into the stories and tasks needed to build all the functionality defined in the Epic. When they're all done, the original scope of the Epic can be revisited. If it is all delivered and the admin can do what was agreed, then the Epic is complete and not to be reopened again.

Later on, when the admin needs more functionality, then it's a new Epic. For example "Enhanced Admin Functions: As an admin, I want more powers...etc.".

In your example, I'd have "Admin Page", "Login Page", etc as components and then use Epics to represent various large chunks of work related to each component.

This, for sure, is the only my personal opinion but I guess all stuff like epics and stories came from scrum process and in Kanban approach you can threat them the way you like.

Foe example EPIC are color specific and I think there are many cases you can use color as a signal (Kanban was founded like signal system).

When you create swimlanes based on epic you might lost manageability and visibility because of many aspects: two much swimlanes never fit the screen and user may faced issues when need to hide some of them o scroll two much. The idea of swimlane is more or less the expedite or make the task over limit.

I would recommend you to set quick filters instead.

Other than that Components  usually more stable so in your case is better to use them in swimlane config.


Log in or Sign up to comment