Does Jira allow aggregated reports across projects

[Steve Brackenbury]

We have decided to create Jira projects with a "product centric" approach.

We have one Jira project for each product offering we have.

We have a QA team that works across multiple products and would like them to be able to generate some reports that capture stats across jira projects (products).

Does Jira have this capability out of the box?

Are there some examples available that we could review?

[Nic Brough -Adaptavist- · Accepted solution]

Very much so - Jira has completely open queries thant can be as simple as "Field is X". So if you've created a field called "products", you can search for "products = car" and it'll pull issues out for the report from any project where car was selected as the product.

The search is a great deal more powerful than that, but, as with all reporting systems, it's important to think about how you get the data IN as well as how you get it OUT. I've suggested a simple "custom field" any administrator can set up, but you've got questions around that. For example, is a single-select list the right way to go (select Car, House or Cheese), or would you like a multi-select (select Car and/or house and/or cheese)?

[Steve Brackenbury]

Thanks Nic.

This is exactly what I was looking to answer. Good to know. We will experiment with some reports to see how it works.

There were concerns that reporting in Jira is project centric. Wanted to ensure that can report across multiple projects if need be.

...Steve

[Nic Brough -Adaptavist-]

It does tend to lead you that way (built-in filters on project screens are obviously project-centric for example, the quick searches have project first, and so-on), as the general assumption is that most users tend to have at least an idea of the project first.

But it really doesn't rely on it. One trick I've seen is people getting filters that work for them in one project, and then they drop the "project = " clause.

The only gotcha in what I've just warbled is that one thing that hangs off project is the configuration. Example - if you create a field for "product", you need to say which projects use it. You then run into fun things like "because field X only applies to project Y, I don't see it in searches that include project Z". So you need to think about context of fields you'll be searching on as well. Although, it sounds to me like your "product" field is probably pretty much "global", so those issues go away.

[Steve Brackenbury]

Like your recommendation of using some of the built-in filters at the project level and then removing the project clause. Thanks for pointing out the caveats with this approach. Will do some experimentation.

Thanks!

[Jeff Kaffenberger]

Depending on what information you are looking for. You can certainly have GreenHopper boards that span projects using a filter like -

project in (project1, project2, project3)

My QA team uses project categories so we don't have to list all of the project we support so our filters look like -

category = MyCategory and type = "Qa Sub Task"

We use Confluence Jira Issue gadgets for "In Test" and "To Test" to see what we are currently working on, and what is in our queue. We also use Created vs Resolved Charts for bugs which filters span projects.

[Steve Brackenbury]

Thanks Jeff.

Good to know. We have a team that is using Greenhopper and they have multiple projects, so this approach could work quite well for them. Good to know they have this option.

...Steve