Bundle multiple boards and sprints into single view

[Kerry Haider]

At an agency, we have a slightly different use case for Jira, and I'm not sure how to best structure it. Ideally, I could see all the work, across all projects for a given team, for a two-week sprint, in a burnup report.

Each agile team has multiple clients. Each client has multiple projects. And each sprint can be comprised of various numbers of tickets across all those projects. How can I set it up so I can track clients, but also the team's entire body of work for a sprint? 

Given this rudimentary image, I'd like to see all the yellow boxes in a burnup (or other sprint report), while still being able to have backlogs for the green boxes.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

There's a general principle in how Scrum, Kanban, and other things provide issue-tracking that fits well with Agile.

Think of a board as representing a team.  (Jira Align goes further - the board IS the team, end of story!)

In Jira, a team is a view of a set of issues, not a container (projects are issue containers).  Even if you set up many different projects, a board can select issues from many places.

So, yes, you can do it broadly as you've described, but with one problem - velocity and burn are a) different for each team and b) belong to the team.  For all sorts of reasons, one team's estimate of a  piece of work may be very different.

A fantastic example I worked with was a team heavy on developers of one language and the other a different language.  Both teams were Agile. They had people who worked with one, or the other, or both.   If you gave them the same task, one team would estimate eight story points, the other three.  That makes it impossible to aggregate upwards.

Your teams will be working in their own sprints, not a giant shared one.  (Best practice is to co-term these - every team does two weeks, everyone ends the old one Tuesday morning, and starts the next Tuesday afternoon for example, but each team has their own board and sprint)

You can do some reporting by having a giant board, but it'll draw in all the separate sprints, and this is likely to be far too large to work with sensibly as well, possibly non-performant).  It would be best if you looked at reporting a bit differently.

Oh, and I've not mentioned clients - I think your mapping to projects is precisely right for this!

[Kerry Haider]

Since it's tracking the work of a single team, they all estimate the same. Is there any way to be able to aggregate project work to see how points and velocity are unfolding within and across sprints?

[Nic Brough -Adaptavist-]

As a single team, they should only have a single sprint.  There's no need for aggregation across projects, your boards (and hence sprints) will be cross-project, selecting what the team needs to work with.

[Kerry Haider]

Hmmmm. I don't think I'm describing this well (or my Jira permissions are hamstringing me - both could be true). 

Scrum Team A has four clients. Each client has a two projects: one for their retainer work and one their contract work. As such, the team works on eight distinct projects in every two-week sprint. 

The current procedure is to set up one sprint per project, which makes all eight projects visible under 'Planning' --> 'Active sprints'. However, there doesn't seem to be a report that can bundle all eight into a single view/graph. Ideally, if each of the eight projects had ten tickets, I'd like a way to see the progress on all 80 sprint tickets as a single burnup chart.

Given the limitations of the project/sprint construct that are established at the company level, is there any way for me to get a better overview of my team's portion of the work?

[Nic Brough -Adaptavist-]

Sprints are team items, not reporting functions, there's no "single view" because you don't need one.

What you probably need to be doing is adding your (cross-sprint) items into Epics, and using Advanced Roadmaps to report on them.

[Kerry Haider]

Oh, I'm so confused. If a sprint isn't a reporting function, then why is there a Sprint Report?

At the end of it all, I'd just like a Sprint Report where I can either choose N sprints to see at once, or maybe something like a sprint report based on a filter. I guess such a thing doesn't exist.

[Nic Brough -Adaptavist-]

Because a team will often want to report on their sprints - especially during a retrospective.  The sprint reports are for the team that performed the sprint, they're not for globalised reporting, you're looking at the wrong thing if you're trying to do generalised reporting with sprints.

[Kerry Haider]

Got it. So if I want to do generalized reporting on a 2-week period, how could I see all of that work at a glance?

[Nic Brough -Adaptavist-]

I would start with an Advanced Roadmaps plan.

[Yuri Lapin _Release Management_]

Hi @Kerry Haider

I hope this email finds you well.

Interesting use case. I would suggest to try our Advanced Agile and Kanban Boards. The Idea of the App is that you can put any Jira standard or custom field as column and/or swimlane. You can also define swimlanes or columns as JQL.

So, for your use case you I could suggest the following:

• you could bring multiple sprints from multiple teams/projects on a single boards (screenshot below)
• you can real time change configuration of your board to make swimlanes per clients
• you can do a mix - have some swimlanes as sprints, others as clients. We support multiple copies of the same tickets in different swimlanes (all copies are identical)
• you can have one board and change configuration on the fly when you need do or you can have multiple boards for your specific configurations.

As @Nic Brough -Adaptavist- explained I would not substitute team boards - let the team do their job and have it they way they want it. This is smth you can do on top exploring same Sprint Tickets.

Hope this helps.

Cheers,

Yuri.