Scrum is a framework for products. A Scrum Team should be a self-organizing, cross-functional team of professionals that is dedicated to working on a single product.

If your projects are separate products, then you should have multiple Scrum Teams. Each Scrum Team would have a Product Owner, Developers, and a Scrum Master. They would be run independently, with their own Product Goals, Product Backlog, Sprints, Sprint Backlogs, and events. You would not need to apply scaling frameworks, since each Scrum Team would be a small team.

However, if the projects are facets of a single product, then you may be able to apply some scaling frameworks. Examples of these scaling frameworks include Nexus and LeSS. However, scaling frameworks should typically be a last resort. A Product Owner, a Scrum Master, and 10-12 Developers is probably on the larger size for a Scrum Team, but it could still be effective. Having a team collaborate and share a focus on a single Product Goal and Sprint Goal would likely be more effective than splitting the focus into 3 disjoint efforts.

Only after you determine the correct organizational structure can you configure Jira (or any other tools). Tools should be configured to support the people and the way of working.

TL;DR

Independent projects should be managed independently, or collectively as parts of a program.

Why Your Team Isn’t a Scrum Team

How should we manage Scrum for a team of over 10 members working on multiple independent projects?

Canonically speaking, whatever you are doing is not actually Scrum. By definition, all members of a Scrum Team must work from the same Product Backlog. Even in scaled frameworks that use adapted versions of Scrum such as SAFe require that each Scrum Team work from a common backlog for each Program Increment even if the individual teams each have their own Product and/or Sprint Backlogs. This is essentially a universal requirement in order for all of the work done by one or more teams to be integrated into a usable Increment at the end of each iteration.

Scrum Prohibits Hierarchies and Unrelated Goals

In addition, the current Scrum Guide specifically states that a Scrum Team has "no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal." If your team is not operating as a single cohesive unit focused on the same product goal then by definition, it is not a Scrum Team.

Other Project Smells

Various other project smells that can be inferred include:

• Independent, task-oriented work assignments.
• Individual rather than team commitments and accountability.
• Lack of collective team ownership and responsibility.
• An undefined, unstated, or possibly non-existent central cohesion that binds the team members, teams, and deliverables together.

All of these point to the likelihood that whatever the business reason may be for trying to call this group of people a “team” they really aren’t one.

Some Pragmatic Options to Consider

You have a couple of different options here. They include:

1. Identifying the business purpose for managing unrelated projects and tracking independent tasks using a framework intended for collaborative development.
2. Assuming a legitimate purpose, you may need to restructure the work to fit a scaled agile context. Scrum-of-Scrums and Nexus are two possible options if the work is really not as disconnected as your question makes it appear.
3. Disconnect the projects and disperse the teams since they are not operating as either a project or a team anyway. This will at least help everyone avoid confusion about the actual project management framework being used.
4. Of course, you always have the option of continuing to do what you are doing regardless of whether or not it is achieving your intended outcomes.

Plan in advance the way you will manage failures

You have to establish a hierarchy to manage the teams you are responsible of. The pyramidal structure is the best known, but you can also innovate and use, for example, a matrix structure that gives a different power to decide to the members of a matrix compared to the members of a pyramid. No matther the structure or the the organigram of your organisation, you will always benefit of giving a clear and consensual description of task to everybody. Your goal is to build a structure were your employees are accomptable of their decision, for example the way they spend their budget. The enthousiasm of the beginings can turn sour when organizational fighting starts after the first failures to generate a profit occur.