Script filter hinders creating new sprints.

[Matthias Nickel]

Hello, 

I have multiple projects which are connected through different common epics, which are all in one project. 

I use the following SQL Filter to show in a project only the epics, which the team has open issues. 

issueFunction in epicsOf("Project = DCE") AND status != Done OR project = DCE

With this Filter, I can't create new sprints. In the board configuration is written, that the filter is to complex to show the involved projects. 

Someone has a solution to that? 

[Nic Brough -Adaptavist- · Accepted solution]

I suspect this is because the first clause could be pulling in issues from all sorts of places (even if you don't have data that would do that, it could do it).  Project DCE might have one or more issues with "Epic Link = <an Epic in another project>"

Normally, you wouldn't draw Epics into a sprint, so I wouldn't be trying to use that filter for a sprint board.

It's a useful filter, I can see that, but I think you need something slightly different for your board if you're going to create sprints in it.

[Matthias Nickel]

I'm using Epic Links to connect many different projects. Like Matrix-organization. People belong to one project team, which works on many different projects. 

Epic are our projects. That's why a connection is ncessary.  All Epics are in mangement project. 

If I use the following JQL: 

Project = MGMTP AND issuetype = Epic and status != Done OR project = DCE

I can create sprints, but the single teams see all projects, even the ones they don't have any issues. As we have like 50 projects in parallel, i would like to reduce the number of shown epics. 

[Nic Brough -Adaptavist-]

Ok, that's not what Epics are designed for, so it's not a huge surprise it is not working well. 

I would consider moving towards a more Agile approach - a Jira project representing a project, Epics being (potentially cross-project) groupings of tasks, and a board being the place a team works.  Then it would be fine for all teams to see everything as you're all working for the big picture, and a board can select only the items that the team owning it needs to see.

[Matthias Nickel]

Not that easy. 

My company is part of a bigger enterprise. This enterprise holds the JIRA licenses and I'have to pay them for each project I create a monthly fee. This might be quite a lot with our more then 50 open projects. 

We have been working with epics as projects( or bigger tasks, which have more like 300 single issues) for quite some time and now want to add more teams to JIRA. It's okay. 

Every member of company can see what the otheres are doing. They have read only access to the other projects and can comment on issues. So we have a good overview about everything

[Nic Brough -Adaptavist-]

Well that sounds a bit broken, as Jira's licencing is by user not project, and you're not using projects, Epics and even issues for what they are designed for. 

[Matthias Nickel]

Yes, but it works fine. And as far as I know, and also seen here in the community, we are not the only ones to use it like that. 

Lots of people are talking about multi project managment in this way. 

I guess, I will find a different way. 

[Nic Brough -Adaptavist-]

I know, but using a Scrum tool to try to do things that are not Agile, let alone Scrum, is going to run into problems.  As you're not Agile, I'd recommend looking towards Jira Core instead of Software, it is better for non-agile processes.

[Matthias Nickel]

Why do you think I'm not agile? You don't know anything about my work. 

But Actually, I don't want to start a discussion. I'm tired of this kind of shit. 

[Nic Brough -Adaptavist-]

I said that because "epics are our projects" is a waterfall approach.