Multiple scrum teams working on a major new feature using team-based release burndowns. Is there a better way?

Question

Ok, a little background. So the company I work for has SIGNIFICANTLY hamstrung the use of Jira. They have eliminated the enhancement and feature issue types among many others to the point where we only have epics, stories, bugs, and subtask issue types available to us.

Problem: we have a new "nextgen" system being worked on and there are about five scrum teams working on it separately. Each team has their own series of epics for their work, so one single epic can not be created and used for this purpose. Because they have removed the feature issue type from use (which would have been useful here since epics roll up to features), they can not get a burndown based on the work they are collectively doing separated by team so instead they have all created their own fix/version release and are using the release burndown to track their work instead.

As the release manager, it is my duty to track, record, maintain, and otherwise ensure that our release procedures and other assorted quality control methods are sorted out so we don't get compromised in an audit situation. What this has done is now I have tickets appearing in multiple release fix/versions where there has (or will have) only one deployment. Policy currently states that any jira ticket that is in multiple fix/versions means that that particular jira ticket has been deployed twice. Now, if we were to be audited, it would obviously get rather confusing to prove when and where a ticket was ACTUALLY deployed.

There has to be another way to track multi-team, multi-epic burndowns. Please someone help me.

Answer 1

I would do the following:

1. Make sure you are using one Jira project. One project in Jira equates to one product. You can also manage your cross-team workflows, issue types, and other settings more easily.
2. Add a custom field to all of the issue types and call this field "Team" or "Scrum Team" or something similar. Set this up so that way an issue allocated to a team will have this field set on it.
3. Create boards, keyed off of this new team field. Each team should have its own board. Depending on your workflows and situation, you may also want to create a board for issues without a team (so they are more visible) and, depending on your workflow, epics to give visibility into their status to management. This will enable each team to start tracking their own Kanban and Scrum metrics, since those are keyed off of boards.
4. Use things that exist across teams, like releases, to track across teams. Your release tracking tools will actually work now, since your teams are tracking their own work on their boards and all work allocated to a release has the same Fix Version applied.
5. Make effective use of labels and components to help build queries for reporting.
6. If you need data, measurements, and metrics, look for plugins. If you don't want or can't get plugins, you can always abuse boards. I've had luck with things like Kanban boards for Epic status or creating a "Release" Scrum board where each "Sprint" is started with the first Sprint working toward the release and the "Sprint" is ended with the release to generate the Sprint-related metrics. There are some interesting ways to (ab)use boards for visualization and metrics.