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

[Ethan]

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. 

[Elliot Reiter · Accepted solution]

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.

[Ethan]

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? 

[Elliot Reiter]

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).

[Geethanjali D · Accepted solution]

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

[Ethan]

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

[Geethanjali D]

Using filters

[Kathi Paquet]

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

[Jennifer Choban · Accepted solution]

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. 

[Ethan]

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]

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.

[Ethan]

@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.

[Oliver Vistisen · Accepted solution]

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 

[Ethan]

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.

[Oliver Vistisen]

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:

https://support.atlassian.com/jira-software-cloud/docs/create-a-board/

https://www.atlassian.com/agile/tutorials/creating-your-agile-board

[Ethan]

Thank you very much for your help. 

[Kathi Paquet]

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.  

[Ethan]

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? 

[Kathi Paquet]

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.

[Swati Rastogi]

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!

[Rowan McLachlan]

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. 

[Vaishali Patil]

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

[Ethan]

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

[caglad]

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.

[Ethan]

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!!  

[Mateusz Janus]

are you JIRA BASIC or JIRA PREMIUM standard?

[Ethan]

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? 

[Arthur Harutyunyan]

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 :)

Thanks

Arthur

[Ethan]

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?

[Arthur Harutyunyan]

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.

[emmanuel asamoah]

YES