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

Jira structure regaring issue types with multiple departments


Regarding the Jira structure in terms of epics, stories and tasks, I'm not quite sure how a good and clear approach can work.

We have the following scenario: There are departments (conception, design, development, etc.) that have tasks in a project. My approach so far has always been:

Epic (e.g. user management)
  Story 1 (e.g. user login)
    Task Concept (e.g. Wireframe login interface)
    Task Design (e.g. Design Login Interface)
    Task development (e.g. Implementation of login interface)
  Story 2 (e.g. user registration)
    Task ...

As our definition to distinguish between a Story and a Task is, that a Story has the user-feature-centric view whereas a Tasks is more as a concrete todo/task for a specific person.

From my point of view this structure has the advantage that the individual tasks (no sub-tasks!) can be scheduled separately in Scrum/Kanban boards (sub-tasks can't do that as far as I know). Another big advantage would be, that each task can be processed individually (boards, backlog). It is also important that there are different time estimates from the departments for their tasks, which are of course more easy to view in the individual tasks than the sum of different estimates in one issue. Also regarding the remaining time estimation in that matter.

A possible downside is that the backlog will quickly become full and the stories will remain mostly untouched in the backlog because with our approach only the tasks itself will be planned in sprints and reordered in the backlog.

Is there any other possible way to handle that? Maybe a different Epic/Story structure? And of course, when a (scrum) guideline would be, that a Story should be small, so that the Story would be finished within one sprint, that would not work with that structure.

I looking forward for replies to that topic and how any other approach would look like. I don't see a "right" or "wrong" here, as this topic depends very much on the internal team structures and other things.



Monika Rani
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 05, 2020

Hi, @Chris van Daele  why don't you create the epic, and under that epic, you can create the small stories that can be finished in the single sprint. try to break down your epic into the small stories in such manner so we don't need to create the many tasks under the stories.

Ed Letifov _TechTime - New Zealand_
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 06, 2020

What most of our customers do is move what you call Epic "one level up" to a custom issue type Feature or Initiative

Your Story becomes the Epic - something you deliver to the user. Your tasks are children of the Epic. You have correctly identified the flexibility this gives you to deliver tasks in sprints with different estimates etc. By moving your Epics "one level up" it also gives you burn-up and burn-down reports for Jira Epics (formerly your Stories), so you can actually see when the user login and user registration will be delivered. 

Also consider the fact that such things like "User Management" usually "never end", as there will always be some user management aspect in a product.

You can just link Epics to Features using regular links. 

If you use Portfolio for Jira or Structure or BigPicture - you can visualise the whole hierarchy there and get various things summed up (time, story points). Usually Project Managers or Program Management Office is obsessed with Feature-level and higher while Developers are quite happy to just dwell on Epic and Task level, as well as Versions/Releases and Sprints.

If you want to go completely frugal - move your Epics (my Features) to Jira's components.

We ourselves use EasyAgile StoryMaps heavily with hierarchy (based on Portfolio Parent Link) of Customer->Initiative->Epic->Story/Task, with quick filters configured for the board and story map view based on Initiatives.


Log in or Sign up to comment