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.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, as mentioned above consider using Components and Labels to break down the tasks and group them together.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Create a QUick filter on your Sprint board so you can select to see only those issues
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
YES
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Jira Administrator
Configure Jira Software, Jira Core, or Jira Service Management, including global settings, permissions, and schemes.
Managing Jira Projects Cloud
Learn to create and configure company-managed projects in Jira Software and partner effectively with Jira Admins.
Learning Path
Become an effective Jira Software Project Admin
This learning path is designed for team leaders who configure Jira Software projects to match a team's processes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.