Any logical reason for a single software development team to have 18 projects for one application?

[Nicholas Hubbuch]

I recently started working at a new company and this company is slowly trying to adopt a more Agile development approach. I have been tasked with helping implement this and assisting in Jira adoption/best practices. There is a team that develops/maintains one software application (that houses 18 sub-applications). This team has 18+ projects, but only conducts four sprints at a time (three sprints for the three largest sub-applications/projects and one sprint for any work from any of the other 15 sub-applications/projects). The team consists of about seven core members. I am not a Jira expert, but have utilized the tool in previous positions and, to me, the established approach seems counter-intuitive and convoluted as it is difficult to get a sense of their entire backlog and it is nearly impossible to prioritize stories.

Prior to suggesting a change (this particular team seems hesitant to change), I wanted to ask this community for feedback and any potential reasons why this should be the Jira methodology we move forward with - Has anyone ever known of such a small team that only works on one application (with multiple sub-applications) utilizing this many projects? Would components or labels not be a better way to organize the sub-applications?

Thank you,

Nick

[Piotr Bojko]

Projects are independent units when it comes to versioning (and release management). So, if those subapps have theirs own, separate versioning - there are projects for me. 

Also, when the customer or an user of your software system sees only part of it, one sub-application, maybe there would be better to track this relationship (user -- subapp) as a project, not a component.

In all other cases one project with components is a great startup point.