Best way to give a sub-team its own scoped agile reports (velocity/burndown)

[Bailey Lissington]

We're on Jira Cloud Premium. A larger team works in one software project, and within it we have smaller sub-teams. Each sub-team would like its own velocity, burndown, and sprint report — scoped to just their work — while we keep a single cross-team view (we already use Plans / Advanced Roadmaps for the roll-up).

What I've found so far:
• The project is team-managed, so it has a single board — I can't add a second board scoped to a sub-team.
• Board and backlog filters (assignee, labels, custom filters) only filter the view, not the reports.
• The velocity chart, sprint burndown, and sprint report are board/sprint-scoped and can't be narrowed to a sub-team.

Given that, what does Atlassian recommend for this situation? Specifically:

1. Is the recommended pattern to give each sub-team its own team-managed project (so each gets its own board, sprints, and reports) with Plans rolling them up — or to move to a company-managed project with one board per sub-team, or something else?

2. Does the answer depend on whether each sub-team runs its own sprints vs sharing one team-wide sprint? If sub-teams share a sprint, is there a supported way to get per-sub-team velocity/burndown, or is the team-level number the only meaningful one?

3. If splitting or migrating is the recommendation, what are the main tradeoffs and gotchas to plan for (sprint history, components, custom fields, the estimation field)?

We're trying to keep the setup as simple as possible and avoid unnecessary structure or paid add-ons if native Jira can handle it. Thanks!

[Alexey Pavlenko _App Developer_]

Hi  @Bailey Lissington ,

Yes, usually people create boards per smallest group of people. Especially when you need separate reports. But it comes with a trade-off, you will need to switch between team reporting tabs constantly in order to check each report. If you need a unified view, you can try the app I developed - Multi-team Scrum Metrics & Retrospectives.

With it, you can:

• Track:
  • Data across sprints, months, quarters, half-years or years. 
  • Several teams (including those ones sharing the same project) at once.
  • Velocity, capacity, allocation, completed story points (completed scope), planned (initial, final scopes), added and removed scopes, as well as other metrics. You can even create your own custom metrics using JQL.
  • Trends and average metrics across periods.
• Conduct Quantifiable retrospectives.
• And many more.

3 boards/teams in the same view, 1 period selected for analysis:

3 boards/teams in the same view, all periods are clicked for average metrics and dynamics:

Best regards,
Alexey

[Danut M _StonikByte_]

Hi @Bailey Lissington,

Unfortunately, there is no easy way to handle this in Jira without using an add-on, especially when using team-managed projects.  

If you decide to use an app from the Atlassian Marketplace, you can solve this requirement easily with the gadgets provided by our Great Gadgets app.

Solution using Great Gadgets:

1. Create a Jira dashboard to track your cross-team (global) project and add all the necessary gadgets, such as:
   • Sprint Burndown
   • Release Burndown
   • Velocity
   • Cumulative Flow Diagram (CFD)
   • Cycle Time
   • Pivot Tables
   • Formula gadgets
2. Use the Great Gadgets Controller gadget with predefined presets (filters) for each team, allowing you to switch views and visualize data for individual teams or the entire project. When you click Apply the selected team filter will be propagated to the other app gadgets from the dashboard showing the diagrams for that team.

With this approach, your existing Jira setup remains unchanged while providing an effective and flexible way to monitor progress at both the global project level and the individual team level.

If you have any questions, feel free to contact us at support@stonikbyte.com.  

Danut.

[Joshua Brock _ Seibert Group_ GmbH]

Hi @Bailey Lissington and welcome!

You've diagnosed the core constraint correctly: in a team-managed project, there's a single board, and board/backlog filters only change what you "see", not what the velocity, sprint burndown, and sprint report are calculated from. Those reports are board and sprint-scoped, so there's no native way to slice them down to a sub-team inside one team-managed board.

The most reliable native pattern for what you're describing is to move to a company-managed project and give each sub-team its own board backed by its own saved filter. Company-managed projects support multiple boards, and each board gets its own velocity chart, sprint burndown, and sprint report, so each sub-team gets genuinely scoped reports while you keep the single cross-team picture in Plans/Advanced Roadmaps for the roll-up.

The main tradeoffs to plan for: sprint history generally does not carry over in a migration, so historical velocity restarts; components, custom fields, and the estimation field need to be re-mapped; and you'll want to decide upfront whether each sub-team runs its own sprints or shares a team-wide one. That last point matters a lot, that being if sub-teams share a single sprint, the board-level velocity is the only natively meaningful number, because velocity/burndown are sprint-scoped. Per-sub-team velocity really requires each sub-team to run its own sprint (and therefore its own board).

So, if you want to stay native and keep it simple: company-managed project; one board (and one sprint cadence) per sub-team; plans for the cross-team roll-up.

If this sub-team structure is the start of a broader move toward scaled agile, with multiple teams feeding shared increments, and you need both team-level and program-level reporting. That's the point where a purpose-built layer starts to pay off. Agile Hive is worth a look there:

• It models a full Portfolio → Solution → ART → Team hierarchy directly in Jira's data model, so each team's work and reporting is scoped automatically rather than maintained through separate boards and filters.
• It supports native Program Increment (PI) planning and execution, with both per-team and cross-team views built from the same data.
• Team-level and ART-level reporting sit side by side, so you don't need a separate tool just for the roll-up.
• Everything stays inside Jira — there's no sync to an external system of record to keep aligned.
• For SAFe at scale, it typically carries a lower total cost of ownership than Jira Align.

You can read more at https://www.agile-hive.com, and there's a free trial on the Atlassian Marketplace if you want to try it against your current setup.

In full disclosure, I work at Seibert Group, the team behind Agile Hive.

Hope this helps!

Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

[Tomislav Tobijas]

Hi @Bailey Lissington ,

I'm not a fan of team-managed spaces, but you do exactly that > multiple team-managed spaces (one per sub-team).

Now, what I implemented last year was for an org that uses the Spotify model (Tribes, Squads...), where we used company-managed spaces with separate boards. 👀
Basically:

• Space = Tribe
• Board = Squad (one per sub-team in your case)

I haven't migrated the existing approach to another, but I'm pretty sure that the sprint history does not migrate. Fields, on the other hand, are easier, but you'll still need to follow some specific steps (one example article here).

In the end, it might be a bit time-consuming and will require prep., but if you ask me, I'd go with company-managed spaces as you'll probably resolve pretty much everything with that. 🤔

Cheers,
Tobi