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]

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!

[melso]

Alice,

Great reply, very concise! I like the recommendation of using releases for the phases, that feels like the piece I was missing.

As I have been reviewing the current reports, I've found they've all settled into one of several categories: Forms, Reports, Exports and Controls, and I was considering using Components to identify them. In light of your item #2 above do you see an advantage using Components either way?

I've had a tough time trying to figure out where to utilize components, they almost feel like tags/labels to me, but not sure if there is more to them or not...

Thanks again for taking the time to share your experience, it's really helped to bring this task into focus for me!

- Mike

(PS - Thanks for the link, looks like I have some homework tonight!)

[Alice]

Glad you found it helpful! I feel kind of the same way about components. They seem very similar to labels. The best way I can think we'll end up using our "Component" categories is for reporting. Once we start doing more maintenance releases, we can see based on each release or sprint how much time we're dedicating to configuration changes vs. customizations vs. security updates.

In your case, if all of your updates relate to different types of reports, it may make sense for your components to be the types of reports. Then you could assign a ticket to the type of report it supports and see how much time you're spending working on each type. I haven't done as much research into the benefits of components vs. labels since we haven't started reporting a lot yet, so that might be something I research further as we continue to use JIRA.

I hope everything goes well with your implementation and project!

[melso]

Did some experimenting last night, and I think I will proceed with using Components as type of report, and Epics/Stories/Tasks as you suggest above. Everything seems to fall into place nicely -- certainly better than creating nearly 200 projects!

I had a reply from the instructor of a JIRA course over at Udemy yesterday that essentially confirmed the same recommendation you made (eg - using Epics for the reports and Stories/Tasks, etc, for the respective work). It's nice to have third-party confirmation! :)

Thanks again for your reply, and best of luck with your project as well!

- Mike