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

[Pankaj Mahajan]

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 

[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.

[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]

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.

[Nic Brough -Adaptavist-]

Yes, but I think you've missed the point of the question.  The report they're looking for is not what you appear to be describing

[Jordan Bauman]

I was just giving examples, of other instances where report accuracy is highly dependent on its goal and scope. If I am correct that this is the same/ a similar issue to mine, I did not feel like saying it is inaccurate or deceptive was a good reason that past sprints are still showing even after specifying not in closedSprints().

I specifically want to have a structure of my team's work in the active sprint, future sprints, or the backlog so I can have a report of work to be done and when/if it is slated to be worked on. I get the exact same issue where I still see past sprints because some of my epics were worked on in that sprint and the work wasn't completed and got moved to the next sprint. So I think myself and Pankaj are seeing the same issue. 

I want to see only the current and future items for planning and quick reference, but for what I use this particular report for, I have no need for the past sprints, even if they have work that is still ongoing in this sprint is also a part of that sprint. As long as it wasn't work that just never got completed and moved to the next sprint, it is just clutter that I have to repeatedly over-look.

[Nic Brough -Adaptavist-]

Ah, hang on, there's an issue here - you don't really work on Epics during sprints. 

Epics are containers for stories, they are not sprint items.  What sprint you worked on the issues they contain is not important.

Also, you seem to be thinking of sprints as containers of specific pieces of work.  They are not, they are time-boxes.  If you want to look at work in progress and work to-do, look at your open issues.  The sprints are not for planning at a higher level, they are for a team to time-box their work.

[Jordan Bauman]

Oh okay, I see what happened. I was meaning user stories not epics.

I understand that Epics are not measurements of times or are actually worked on themselves during a sprint. As well as a sprint is nothing more than a pre-defined time-box (generally 2 weeks) for both a team and the project manager to break down work into a certain granularity, but also provide time-frame estimates for which the business uses to plan. I use the term sprint not as a container, but as descriptor, like saying "last month's rent". The rent is not contained by the month, but is typically aligned with it. So a sprint does not contain user stories, but that is describing that instance of work that took place during that sprint.

But when you said: "Epics are containers for stories, they are not sprint items.  What sprint you worked on the issues they contain is not important.", you are right; I was meaning user stories, but I have everything also grouped by epic, and I was getting confused. So when I mentioned epic in my comment, it should be user story instead.

I want to look at the user stories planned for the current sprint, future sprints, and unassigned user stories. I do not want to see any previous sprints or the stories worked on. However, when I try to filter out previous sprints, any sprint that has user stories that were time-boxed during that time and moved over to new sprints, still appear.

So for instance, I have a user story that is broken down to the right size, but due to inter-team dependencies, has been moved through a few different sprints while waiting to be started. When this happens, it creates a grouping for each of the previous sprints it was in, its epic, and another line-item for its user story itself. So the report is displaying duplicate records for each of the associated sprints. Which causes a lot of clutter if you have a couple of these user stories out there that are waiting to be picked up, but are still needing to be in each current sprint for team visibility.

Seeing the leftover items can be helpful, but for the purposes of this report, I don't want to see the previous sprints. I am just wanting "sprint not in closedSprints()" to not display user stories from past sprints.

I know this is largely handled by the team backlog that is provided by default, but I like to be able to add different field values in the columns and have calculations if need be. So I would love to be able to use structures.

[Nic Brough -Adaptavist-]

So I think you're still missing something here.

You say "I want to look at the user stories planned for the current sprint, future sprints, and unassigned user stories."

That tells me you are trying to do future work planning.

But then "I do not want to see any previous sprints or the stories worked on." and then talk about not wanting to see "moved to new sprints"

That makes a nonsense of your planning, because you are now choosing to ignore issues that still need working on.

This is why I'm saying the sprints are not what you should be looking at.  If you insist on looking at them, that can work, but you have to stop saying you don't want to see issues that have been in closed sprints.  You can't plan by ignoring work that still needs doing.

[Jordan Bauman]

This is my report for just generally looking at work ahead and for quick reference. I simply want to know if I can do this, and if so, how?

It will take a long time and a lot of back and fourth to describe my entire team configuration, methodologies, reporting structure, training, etc.... I am not using this report to give my director a completion date or any information. This is for me to look at as I am going through most of my weekly meetings as a quick glance that I can either look at it from the epic level of general work, or quickly expand to see the specific deliverables of that epic.

We handle all of the detailed nuances of planning in specific meetings, where I use different charts and reports. However, in every other meeting I have, I don't need to know that user story xxxxx was started in sprint x and was moved over in (a, b, and c sprints). I know that is an on-going user story that has been going for multiple sprints. If I need that level of detail I can go in and click on it.

So I would not like to see past sprints, because as I said before, different reports (with different uses, outcomes, and defined scopes) require a different set of displayed information. This is not a master report that I use for every decision I make, just a reference sheet that I find helpful and it could be a lot more helpful if I could make the specification to see or not see duplicate user stories from previous sprints. Not that I want to remove the functionality all together. Just to remove it from this report.

[Nic Brough -Adaptavist-]

So the problem here is still "So I would not like to see past sprints"

That 

• misses the point of doing sprints - they are for your teams to do their planning, not higher-level bits of your organisation
• past sprints inform capacity, not planning
• it does not work, because you are choosing to ignore work that still needs doing.

I think you need to take a step back and look at what you are actually trying to plan and report on.

There's still a lot to unpack here, but the starting point is "why do you think sprints are a way to plan (outside the single team)?"

Why are you not trying plan based on the issues you actually have, instead of team time-boxes within which your team work? 

[Nic Brough -Adaptavist-]

I'm sorry you feel this way, but I am really trying to help.

A big problem for me is that you're writing essays covering huge swathes of stuff we could be talking about and I'm trying to get down to a short answer that will actually help, rather than just take us off down another path that probably won't help.

Can we go back to the basic question (and yes, I know most of it is in previous posts, as will be a lot of what I'll try to say or explain).

What information are you trying to see, at a high level and what are you trying to do with it?  What is it supposed to be telling you, and helping you do?

Not sprints, not issue details, not dates, not the raw data, but the "story".  Something like "I want to be able to plan the outstanding work, and I want to see it in shape XYZ"

[Rthomas]

Reading this thread has been maddening. I have the same issue as @Jordan Bauman , and the entire thread is a community leader ignoring the main question completely to give their take on how agile "should" work. 

So dismissing the fact that they have been condescending and unhelpful for the life of this thread. 

Is there a way to hide previous sprints in structure. If yes, how? If No, cool thanks. But you don't need the why to provide information to people asking questions on a forum, its completely irrelevant to the question. 

We don't need to hear about scrum/agile theory, its a question about how to use a feature on Jira. 

Its taken 6 months to not have the original question poised by @Pankaj Mahajan 

[Gideon Nieuwoudt]

I'm with Rthomas on this one - came to this thread with the same need and read through it all only to be confronted by lessons on Agile, instead of help with the query.

So is there a way to do this?

[Nic Brough -Adaptavist-]

I'm afraid Rthomas and yourself are still missing all the points made.

Nobody went back to the question and re-read it, then expanded on why my answers did not explain it.

Again, to answer the original question, the query contradicts itself, and the follow-up questions diverge away from it.

[Jordan Bauman]

@Nic Brough -Adaptavist- I tried multiple times, you said I was writing novels.. I have re-read this question dozens of times. You can't ask for expanded answers and then shut them down for being expanded.

fact: there is over 1200 views and no accepted answer or upvotes. 

[Nic Brough -Adaptavist-]

So when you go back to what was originally asked, what are you struggling with? 

You have not answered the questions I asked last August (or before) and without the information on that, no-one can give you an answer.  We need to know where you are stuck.