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

I am looking for suggestions how we can organise tickets in a large project to manageable size?.

We are going through a process of converting from Internet Explorer to MS Edge for our core software.  As we fix blockers to allows functions to work so testers can continue to find if subsequent screens works on Edge.  We have over 100+ jira tickets and we currently tag them all against an epic so we can have a whole view of the issues. 

We would appreciate suggestions from those more experience how we can go about breaking it down into manageable size per sprint but yet have an overview of the progress of the whole application conversion.

Thanks in advance. 

10 answers

4 accepted

4 votes
Answer accepted

Consider having more than one Epic, use components to tag related issues, and even consider using sub-tasks to break down an issue into smaller units of work.

Currently, we only have one project setup to get an overview of all the various changes on-going in the application. If we use more than one epic, can i still get an overview of the this browser conversion project? 

Without knowing the full details of your requirements, I would suggest to use Epics as swim lanes in your Kanban and Active Sprints boards, and possibly use Quick filters on Components to help focus on related issues (if you decide to use Components).

Like # people like this

Yes, as mentioned above consider using Components and Labels to break down the tasks and group them together.

How do i group components and labels together and get a view of the issues in a sprint?

Like Ethan likes this

Create a QUick filter on your Sprint board so you can select to see only those issues 

Like # people like this
1 vote
Answer accepted
Jennifer Choban Marketplace Partner Jul 15, 2021

Depending on the volume, you might want to consider starting with a single issue to represent an epic with a checklist on the issue (note that I’m part of the Issue Checklist for Jira team) to capture the stories. This is useful if you have lots of Epics and are unlikely to get to one/some of them for several months. The checklist gives you a place to keep the story ideas without cluttering your backlog. Then when you’re ready to develop the functionality, you can create an Epic and an issue for each item in the checklist. 

I like the idea of 'not cluttering the backlog'. 

However, I am have trouble trying to work out what you meant by "starting with a single issue to represent an epic with a checklist on the issue (note that I’m part of the Issue Checklist for Jira team) to capture the stories." Can you please clarify?

Jennifer Choban Marketplace Partner Jul 16, 2021

Sure. Let’s say my company is planning on building a new website, but we’re probably not going to start on it in the next few sprints. I could create a New Website Epic with issues for each task needed (decide structure, source images, make home page, pricing page, etc.).

Alternatively, I could create one issue called New Website and store the list of tasks as a checklist. All of the information is preserved, but it is only taking up the space of one issue. Later, when I’m actually ready to begin work on it, I can create a new Epic and can create individual tickets from each of the checklist items. It just gives you a way to keep the number of items that are in the backlog at one time from getting out of control.Epic.png

Like # people like this

@Thank Jennifer.  Appreciate the explanation.  I will try out a combination of some answers from above and yours to work out what will work for our Sprint Active Board view.

0 votes
Answer accepted

In addition to using multiple epics, labels, components etc... to allow you to better organize the tickets within the project, I would also recommend different boards within the project.

You can setup each board to have a different JQL filter, showing only the tickets you want on each based on label, component, assignment or a combination of properties.

  • Product Managers get a list of epics
  • Product Owners get a list of tickets to epics to which they're assigned
    • filter one for tickets still needing user stories and acceptance criteria
    • filter another for tickets that need pointing
    • filter another as the 'ready' for scrum backlog 
  • Scrum Teams can each have a scrum board with relevant ready work and the current sprint work

The combination of Epics (~50) and Boards (~10) makes our 2000+ ticket project manageable at scale 

Thanks @Oliver VistisenSounds like a great idea. I like this as that was what was troubling me, i.e. how do i group and get an active board overview of all on-going epics and tickets. 

Can I confirm my understanding of the option you suggested  - I only have one project created and all epics and all kinds of work is in this project.  Now we have a parallel  project where the whole application need to be re-tested on MS Edge and bugs fixed. I want to manage this project separately from our current sprint board?

Your suggestion is just what i need.  Is there some page where i can get help how i can do this please? Better still if there is a video that can help show me how this can be done as I am still a novice jira admin.

Depends on which project type you're using in JIRA, but if it's the classic company-managed type you can create a new board from the board selection menu (see below).

Here are a couple of articles following a quick good search:


Like Ethan likes this

Thank you very much for your help. 

2 votes

I agree with @Elliot Reiter  I have used components to tag the related issues for it allows me to utilize the custom gadgets in JIRA to see how many issues open/resolved based off component.   I would also suggest  having more than one Epic where the Epic can be a 'grouping' of related issues.  

I think i get it now but it seems to me that I need a separate project to encapsulate various epics for an overall view.

I am new to this as i did not setup the project and not sure how separate project will work out.

Do you know what is the appropriate way to start a separate project and have all the workflows  from this current project copied over? 

I am not for sure you need a separate project for I wasn't suggesting creating a separate project.  I was suggesting to use the Epics and can still utilize components and labels at the Epic level.

Like Ethan likes this

If on Premium version, it'll be helpful to use "Plans" feature to create Initiative and have the hierarchy under that, it can contain more Epics as bucketed items and gives a gantt chart like visual representation on the progress. 
You can also create multiple 'Teams', and base the boards filter based on that each team can access their own work and on the Roadmap can have the full overview. Teams is part of Premium too, instead of that components can be used too.
And ofcourse, it's important to have regular reviews and retro meetings to help get the information shared across various teams!

As many have said, multiple Epics to break down into smaller groups of tasks is a good way forward, but using Plans and Initiatives on top of multiple Epics is a great way to work, as you can track dates and progress quite well for large projects. 

Like Ethan likes this

As others have mentioned, more epics would help segment the issues. In my experience, the using releases helps with prioritization. I use Adv. Roadmaps to get an overall view and in addition to ease of planning helps with monitoring

Appreciate your suggestion. I do have some concerns about advance roadmaps as we have not started using roadmaps yet. 

0 votes
caglad Rising Star Jul 15, 2021

If you want to keep it all in one epic then consider using fix version to break it up into smaller releases. Then you can run reposts of the fix version.

Thanks.  We can do that. One previous issue we had was such tagging could increase the items in our Release board and confuse our testers and others looking at the release board!!  

are you JIRA BASIC or JIRA PREMIUM standard?

We are on Jira Cloud Standard Plan. Not sure if this answers. Where do i go to find out if I have Basic or Premium? 

Hi all. @ETH let me share some of the tricks from my experience. 

How Im organizing my 10+ projects with 1k+ tickets in each :)

Im doing several micro projects inside the one Jira project. So, Im separating those in a logical epics. If there are big tasks in my microproject, Im breaking it down with the following structure:

Epic -> NewFeature -> Sub-Tasks

I like this approach. Though, I would like to have Epic -> NewFeature -> Task -> SubTask, but the current Jira implementation does not allow to do so.

I described the general structure of my ticket-structure in the projects, but beside that Im using Jira components, and mostly Im using Jira labels (note, that label is the only cross-project item. So you can mark 2 tickets in different Jira project with the same label)

I also have incremental iterative projects where Im using Scrum Board with sprints inside.

I have a special Jira project for my designer. He is just making some designs there and delivering to my team with tickets. Here Im using a simple Kanban board inside a very simple Jira Next-Gen project

Of course, our comments are just simple experience-sharing, but as @Elliot Reiter mentioned above, we do need to know all your requirement to advise the best way to organize it. 

Anyway, we reach to our "best-way" trying different approaches. And Im sure, this is the only way :)



Thank you for kindly sharing your approach. Appreciate it very much @Arthur Harutyunyan Your notation about label is very useful as it will certainly come in handy.

Can i ask you where can i get more information and help on creating micro projects within one project?

Hi @Ethan thats perfect, nice to hear that my comment will be helpful for you. 

Actually by saying "microproject" I meant the software projects inside one Jira project.

For example:

Lets say, we have a Jira project called "Development"

We create different products inside this "Development", for example:

1) calculator

2) simple website

3) simple app to simulate mouse click 

So, 1, 2, 3 are software microprojects inside "Development" Jira project.

Like Ethan likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events