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.
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?
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.
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.
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:
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?
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!
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 :)
Hi @Ethan Wong 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.
Lets say, we have a Jira project called "Development"
We create different products inside this "Development", for example:
2) simple website
3) simple app to simulate mouse click
So, 1, 2, 3 are software microprojects inside "Development" Jira project.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events