Board insights and issue source

[jenseilertsen]

Hi,

I work in a large project where we use Jira cloud. We have several teams with separate boards, yet the sprints are managed centrally. The insights (sprint insights / backlog insights, the feature accessible from board) thus shows stats for ALL issues in the project for a sprint, instead of just one team. Is this possible to change?

It is a way for the teams to get some quick stats, and the overall project metrics are irrelevant in the situation that view is most used.

[Yuliia Hushcha _Reliex_]

Hi @jenseilertsen @Boldizsár Vermes 

If you consider using a plugin, I would suggest ActivityTimeline. 

On one timeline view, you can see the tasks from all your projects or specific one. You can also customize the fields on timeline view and see team workload or other insights. 

You can track tasks progress, workload, and availability for each employee taking into consideration the part-time, full-time, or even different work schemes for users, and holidays. Workload or availability could be calculated for individuals or teams on the same view.

If you have any further inquiries, please don't hesitate to reach out. We are also available to provide a demo session if you find it necessary. 

[Boldizsár Vermes]

I am surfing the internet to find an answer to the very same question. I have a Jira project for multiple teams, and we are okay managing them on a single board. But backlog insights are useless on this board. I tried to set up individual boards for the teams, but it did not help.

The best I could find on this page is that:

Although insights live on your board and backlog (and deployments view), they surface project-level data. This is what gives you a holistic view of your efforts and possible areas for improvement.

I am still hoping that there is a solution to the problem that I haven't discovered yet. Or an enhancement of this feature targets our scenarios.

@Erika Sa, I am tagging you because of this announcement of yours.

[Boldizsár Vermes]

Well, I think I found and answer: backlog insights work with the closed sprints that were opened on the given board (hint from here: JSWCLOUD-23104).

So, I am planning to create individual boards for all our teams (board filter: same criteria as the common board + other teams' sprints excluded), create sprints on these (with automation: ensure two future sprints), and use the common board as before.

Bonus: the velocity report works well on the team's board with the filter mentioned above :)

[jenseilertsen]

Thanks for the response. I believe that this fix may not work as well in our situation as, while we need different boards for the many teams, the sprint are ran centrally. Or is your plan then to centrally create every sprint per team/board? I think that would create quite the chaos given the amount of teams we have. 

[Boldizsár Vermes]

You still can centrally see, manage, start, and complete sprints on a single board, sprints can appear on multiple boards. The only need is to create the sprints on the board where you want to see the backlog insights for the given team. I think, planning and starting a sprint for a team can happen on a board that is dedicated to them (issues already put into other teams' sprints would be just noise here). But if this "solution" is not suitable for you, I can understand it too. I hope Atlassian hears us with different scenarios and way of use of backlog insights :)

[jenseilertsen]

Yeah I hope so too, and unfortunately it does not sound like that would fit us so well (although it is great to hear that you had a solution in your case :D).

Case for us is that we have one board "management" where we centrally run and manage the sprints (which are equal for everyone on timing), and then for example "Integration" team have their own board, associating stories to the common sprint. So on their board, they only see their own issues, not for example "UX" team's issues - but the "UX" team issues show up in the insights even if they are not on the board.

So currently, we have 1 "Sprint X" for everyone (which I believe makes most sense, as leadership can look at stats for the overall projects over sprints) - which works for everything but the Insights mechanism. And if we were to have "Sprint X - Integration" and "Sprint X - UX", we would end up with about 30 Sprint Xs hehe