nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to hide the closed sprints from the open sprints, future sprints and backlogs filter

Pankaj Mahajan_1gi1u9

Hi ,

I am creating a filter to display only the issues in open sprints, future sprints and backlogs but when i apply the filter it is also displaying the closed sprints as well.

Is there is a way to hide the closed sprints from the filter results and only display the open, future sprints and backlogs .

This is the below filter i am using :

project = "DPM " AND (Sprint is EMPTY OR Sprint in (openSprints(),futureSprints()) or Sprint not in closedSprints())

Please Let me know if I am missing anything in the filter .

Thanks in Advance!!

Regards,

Pankaj

Accepted answers

All comments

Nic Brough -Adaptavist-

Your query actually contradicts itself, and has little to do with your actual question.

What you want to see is actually a lot easier, you've overcomplicated it by thinking in sprints.

You say "open sprints, future sprints and backlogs", but you could actually just write that as "all open issues". There's no need to reference the sprints unless you actually want to see issues that you've already moved to done and put them in a sprint (which is pretty pointless, as the issues are done)

If you must do it via sprints, then the simple version is to go for a negative, exclude what you don't want:

(Sprint not in closedSprints() or Sprint is Empty)

Pankaj Mahajan_1gi1u9

Hi Nic,

Thank you for the response on this .

Sorry If I could not convey the actual requirement to you.

The main issue is that the issues which are currently under the Active sprint( For ex. sprint 51) were earlier part of the closed sprints (Sprint 49 & sprint 50).

So at the time of closing the sprints 49 & 50 the client moved the issues to the Active sprint i.e. Sprint 51.

So whenever I am applying the filter- basically it should only display the Active sprint i.e. Sprint 51 but the results are displaying the closed sprints as well i.e. Sprint 49 & sprint 50 along with the Active sprints.

I just want to know if its possible to hide the closed sprints from the filter results.

Let me know if you have any questions on this .

Regards,

Pankaj

Nic Brough -Adaptavist-

Ah, it's not the filter then.

" it should only display the Active sprint i.e. Sprint 51 but the results are displaying the closed sprints "

This would be lying to the users though. An issue that is drawn into sprint 49, then rolls over into 50, and then 51, is in all three sprints. It's useful to know that, and a report that fails to show the sprints for an issue would be inaccurate.

Jordan Bauman

However, wouldn't the usefulness depend highly on the report's purpose? I have the same issue, where the report is meant to be current and have a forward focus, not what we were focusing on previously. Even if some of the epics we are currently working on existed in previous sprints. I'm not saying that they did not exist in previous sprints, but I am saying that for its purpose, it doesn't matter and is just clutter that I have to sort through. I can create another view for the over-arching work breakdown if I need that level of detail.

Since the information in previous sprints will never change, nor ever have more work done on or added to them in that sprint, it is not a needed item in this specific report. I like having the ability to keep the related work from previous sprints, but that would only be for those use-cases where I want the background and pattern of work.

So the past sprints are not Active, the epics are. If I am trying to group and filter on the Sprint level, why would that make a difference if it has epics that were also active in previous sprints? If I wanted to see the span of work on an epic, I would group first by Epics and then see all of the sprints it was apart of.

I would also argue that it is not lying to the user.

For example, this is my current need: If I am working on Epic A and it has dragged on a few sprints or months and someone asks: "What work do we have left to complete?". Am I lying to them by not telling them what has been completed since Epic A was started, or am I being more accurate by only providing the information they want/need in that moment?
Or not related to project management: even just a quarterly/annual graph of total revenue by industry or region that does not show the prior year or what customers existed last year compared to this year. It's not that the company didn't exist or was providing an entirely different product, just that it is not a part of the report's scope.

I am all for wanting to ensure accuracy and effectiveness in a report, but there are certain times you want the big picture, and certain times that you want a smaller picture, but leaving off a perspective is not necessarily deceptive.

Let me know if I am missing a variable or something here, because this does seem quite useful for my current needs, and I have just been ignoring the previous sprints. But, either way, it sounds like this was intentional and/or is not seen as a defect. So I guess I found my answer that it cannot be done in structures at this time.

Gideon Nieuwoudt

I don't profess that this answers the question, but I managed to get something that works in the context that I saw this problem appear.

The problem

But first, I think there's some additional information to the version of this problem that I'm experiencing that I didn't see in the other thread: the issue is not that the search query is returning results for issues that are still active in the current sprint that had rolled over from previous sprint; it's that the results also returns issues that were closed in previous sprints and that are not in the current sprint.

My unique use case is that I want to see issues that were also closed in the current sprint. If it wasn't for that, I could adjust the query to only look for "all open issues" as was suggested.

Like I said, this might be unique to my situation. I would expect to still see issues that are open even though they rolled over into the current sprint from previous sprints. That makes sense. But I don't want to see issues from closed sprints in the search query as I'm not interested in that; I only want to see currently open issues that are in the current and future sprints.

One more piece of context

When I search across one project, using the below works:

project = PROJECT_A AND type = Story AND status != Archived AND sprint in (EMPTY,openSprints(), futureSprints())

I get all issues that might have rolled over from previous sprints, but which are still active in the current sprint (they may or may not have been closed in the current sprint - I want to see them all) and I'm not seeing anything that was closed in previous sprints. (And yes, I'm not interested in archived stories, nor sub-tasks.)

The moment I add a second project, the query breaks, in that I get results returned from PROJECT_A that were closed in previous sprints, even though they didn't show up when I ran the first query above:

(project = PROJECT_A AND type = Story AND status != Archived) OR (project = PROJECT_B) AND sprint in (EMPTY,openSprints(), futureSprints())

Yes, I know my query is not elegant and a bit dodgy, but that's why I'm here, right? To find out what's wrong so that I can learn and improve.

The query that works - sort of, maybe

Still not elegant (and possibly dodgy), but this at least doesn't return any results from PROJECT_A that were closed in previous sprints:

(project = PROJECT_A AND type = Story AND status != Archived AND sprint in (EMPTY,openSprints(), futureSprints())) OR (project = PROJECT_B AND sprint in (EMPTY,openSprints(), futureSprints()))

So why does this work? @Pankaj Mahajan @Jordan Bauman @Rthomas are you also trying to search across multiple projects?

Jordan Bauman

Thank you for answering/Adding to this! Unfortunately, since it has been a year since I was on that team, I no longer have this issue to where I can test a filter for spill overs... I ended up exporting to excel every time and filtering that way... I will definitely try it out next time my current team has spill overs.

For me it was just a singular project at the time, though my current team does have two projects. Generally, I have been pulling from the JIRA Board rather than the projects directly, so that might have something to do with it not filtering correctly.

Main issue for me was that if I had a ticket that is open and has been open for a number of sprints, I would see the current sprint with the ticket as well as every other sprint prior with a duplicate ticket. It reflected the ticket in every sprint it was open during and caused a lot of clutter. Since it was an issue with a third-party SME, there wasn't much my team could do about the spill over.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-software

jira-software-server

filter

sprint