How do you track velocity across cross functional teams in JIRA?

[Andrew Tate]

We have a very large development group with many teams.  For example, we may have 5-6 teams working on one product.   In this mode, how can you maintain a common backlog for the product and also track the velocity of each team?   Teams also cross over to other products.  We want to be able to maintain the velocity outside of the project.   Currently the only way we figure this can be done is to align a project with a team which is prohibitive for maintaining a common backlog for the product.

[Ignacio Pulgar]

Sprints are not dependent either on the project or on the board:

https://confluence.atlassian.com/jirakb/sprints-shared-between-multiple-boards-779159068.html

Where to move incomplete work would be decided on sprint closure, and is not project dependent, except for permission checking.

Ideally, only one sprint should be used by all boards at a time, to ensure all of them are in sync.

As suggested in this answer, it is a good idea to include into the sprint an issue common to all teams merely for acting as a Sprint Marker:

https://community.atlassian.com/t5/Jira-Software-questions/How-to-manage-more-SCRUM-teams-for-one-backlog/qaq-p/220057#M5283

By including this marker issue, the very same sprint would be shown on all boards.

Please, note that certain actions in a multiproject board need to count with permissions in all scoped projects.

[Ignacio Pulgar]

Each team needs to have their own Scrum Board for their overall velocity to be measurable through the Velocity Chart.
The board filter needs to be set to retrieve issues from all product projects, and filter out those issues somehow marked as assigned to a different team.
A clean way of doing so would be having all team members in a Jira Group (one group for each team).
That said, the board's filter could look like:
project in (AAA, BBB, CCC) AND (assignee in (membersOf("team-1")) OR assignee IS EMPTY)
However, a more consistent solution could be set by creating a custom field named Team, so that you can avoid having to assign the issue in order to display it just on the appropriate board.

[Andrew Tate]

Unless I'm missing something that won't work as sprints are at the project level not the board view.  For your proposed solution to work all projects would need to use the same sprint cycle.   Each team would not be able to close the sprint until all teams agreed to do so.  Also the decision of where to move incomplete work at the end of the sprint would be at the project level.