Need help with setting up an ongoing maintenance project

melso

I'm currently setting up a project (in JIRA Software, 7.7 ) that manages the initial conversion of an inventory of almost 200 Crystal Enterprise reports to Jasper Reports, and then manages the ongoing maintenance of the reports.

For maintenance purposes each report should be able to track new feature/change requests, bugs, and document updates/reviews, and will be annually reviewed for updates or removal from the inventory.

Where I'm having the problem is picking a strategy to best set this project up in Jira. Should each report be a Project, and all of the relevant issues apply for each report (which seems excessive), and use an Epic to tie them all together?  Should I use Components to sort of sub-project each report under one Project (which seems like it might require more manual effort assign the appropriate Component to the Issue). My fear is that I might miss out on reporting or other functionality, or have to make massive changes to the project later if I get the setup wrong now.

I've used OpenProject in the past for a similar project, and it had a 'master' Project that has Sub-projects for each report. I found a plugin that adds sub-projects, but I'd rather use the default install if possible. I've become the defacto Jira Admin, but my experience is over 5 years old with Jira, and was on a straightforward, beginning-to-end software project.

After spending significant time on this board (and others) I'm not seeing a clear path to what I'm attempting to do. Any help or pointers to examples would be greatly appreciated!

Alice_qq4e4l

Hi Michael,

If I were you, I would set up one project for the entire thing, and then have releases dedicated to the different phases of the project (like initial implementation and then maintenance releases). Then you can create epics for each type of report and have issues/stories within those epics for updates, bugs, and other items you have to do for maintenance. Then those issues/stories can get assigned to sprints to represent different releases. Having it all under one project with separate releases/epics would allow you to start reporting on the different phases of the project and the subsequent maintenance in one place.

We recently implemented JIRA and ran into similar questions, so we created one main "Maintenance" project and set up the different parts of the project as:

1. Epics - large projects requested by end users (in your case, this could be major reports)
2. Components - different types of changes that need to be made (e.g. customization, configuration, security, etc.)
3. Sprints - bi-weekly releases (or whatever short time-frame you use if that's how you release updates)
4. Stories/Tasks - larger ticket items (report requests, security requests, etc.)
5. Sub-tasks - individual items that need to be done to support a story/task

I found this article in the JIRA scrum methodology library really helpful in deciding on this set-up. We don't follow scrum to the letter on our team, but it's helped us come up with a set-up that fits the JIRA software and works with our team's current processes.

I hope this helps!