How can I show only the current sprint value in the issue list rather than historical?

[Tony Iuppa]

The sprint field seems to keep track of all sprints that an issue has ever been in. We have some tasks that are ongoing so they tend to pick up too much history and it messes up the list formatting. 

Ideally I could have my issues list show either the active sprint or EMPTY per item so I can see what's in and out of the current effort. 

For example it shows me Sprint 4, Sprint 3, Sprint 2... I just want Sprint 4 (active) or blank.

Does anybody know how to do this? 

Thanks

[Tony Iuppa]

Not sure about reporting -

We have saved and shared filters which are issue lists including the Sprint column. 

These are to share during standup, during triage meetings with production, or to make dashboards for our teams. 

It would be nice if the Sprint column in the list view only shows the most recent sprint (or blank). The more sprints listed on any single issue, the greater it impacts the usability of the filtered list. 

[Nic Brough -Adaptavist-]

That sounds pointless - you don't need to see the sprint on each issue if you know you're working with "latest"

I suspect the problem is you're using the sprint to search, so you're pulling back too much.  Have you tried "sprint in openSprints()"?

[Tony Iuppa]

Hi Nic, thanks.

For several filters we do not search on the Sprint.  

An example use case is our support team delivers 15 issues from the community that we want to triage. 

We are walking the list of that filter to evaluate priority and add some to the Sprint for our devs that have time blocked out to fix bugs. 

It's helpful to see the whole list and whether or not any issue has been added or not.

If we ever assigned a bug fix to a sprint and it doesn't get completed and is pushed to a new sprint then the next time we walk this list that issue will have multiple values there.

[Nic Brough -Adaptavist-]

This sounds very clumsy to me - you don't need to see the sprint information to do this process, you just use the backlog planning to do it (Where the sprint is available to drag into)

[Tony Iuppa]

Okay Nic thanks for your input. 

[Vyas Thottathil]

@Nic Brough -Adaptavist- - I certainly dont think it is clumsy, pointless or wrong, considering the insane number of questions and requests on the internet to solve for this. For certain reports to leadership, we may need to do an export (which is why we have that functionality in jira). In the export, there is no easy way to get the current sprint. If you would like to have the history of all the sprints the issue resided in, thats fine.. But what you did not answer is how many of us can get the current sprint to which an issue(s) is assigned to, without having to do string manipulation in excel or using BI tools.

I have found responses on this thread to be very dismissive.

[Vyas Thottathil]

All we need is an additional column called Current Sprint (and it can be empty if unassigned) option in the export.

[Nic Brough -Adaptavist-]

You can include the sprint field in exports.

I can't find an insane number of questions or requests on the internet for this, I've found a few, all of which have been answered by pointing out that the reason behind doing the export is a clumsy and pointless process.  If you use the tool as intended, you don't need it.

[Vyas Thottathil]

Answering by asking to use tool as intended, is not a solution to any of the users facing the problem. I am sure you know that when you responded again with the same.

[Nic Brough -Adaptavist-]

The problem you're having seems to be a result of not using it as intended, not a problem in the software.

I would question why you are doing that and look to fix that instead of asking to reduce the functionality of the software.

[Cheri Kircher]

If there is a business use case where it is required to only show the most current sprint assigned to an item then I don't believe it should be questioned.  It is a need that many have requested therefore should not be dismissed.

[Vyas Thottathil]

@Nic Brough _Adaptavist_- I take offense in business case by the users being referred to as clumsy & pointless in a number of your responses. As a community leader, I would certainly expect a more receptive frame of mind than to shoot such dismissive responses.

I am however glad that you asked for the business case. I will repeat as you seem to have missed what I mentioned earlier - "For certain reports to leadership, we may need to do an export (which is why we have that functionality in jira)"

I am not asking to reduce functionality, which seems to make me think you are responding so far, without really understanding the request. The request is to add an "additional column called Current Sprint (and it can be empty if unassigned) option only in the export". It already exists in the jira interface - not a new field request. The field is called Current Sprint.

Having to parse through a field to get data that is visible on the jira screen, is really painful.

[Nic Brough -Adaptavist-]

I am sorry you are offended, but those are not my words, they are the words I found on the responses on the tiny handful of requests I could find asking for this (not "insane number" as you misrepresented it as)

Before castigating me for being stubborn, could you please read what I've said properly?  Your previous comment clearly shows you have not bothered to read or think through what has been said before, and that could be seen as offensive as well.

[Robert Prater]

This isn't just for exports though, Nic.  I've been googling this for about 20 minutes now and there are way more than a "tiny handful of requests" for this issue.  All are about as frustrating as this thread. 

I have a bug that was dragged through 3 different sprints because no one could figure it out.  Now when I build a dashboard, it's showing me a column for each sprint that bug was in (so 3 columns of sprints)...the reporting is intelligent enough not to count that issue 3 times, but it it is confusing for me and the leadership team that I build the dashboard for.  

[jan vasile]

Exactly what Robert Prater says.  We need an additional column that contains current sprint, future sprint that might already be assigned, or backlog.  In this special new column, past sprints should be weeded out.  It is valuable to capture an issue's sprint history, but this request is for more than that. It is to provide a clean way to identify and report where the issue is at present. 

[Vyas Thottathil]

@Nic Brough _Adaptavist_ - Can you advise on next steps, if any? Thanks.

[Ben Romberg - codefortynine]

Hi there,

it may be possible to solve your problem by creating a dynamic field with our Jira cloud app Dynamic Fields for Jira.

With our app you can add a field to your issues that only displays the active sprint of the issue. This field can be used for reporting and within JQL queries.

Here's an example about how the expression of your dynamic field could look like. Of course this is only an example and it's possible to customize it:

issue.customfield_10003.filter(sprint => sprint.state == 'active').map(sprint => sprint.name).reduce((a, b) => a ? a + ', ' + b : b, null)

"customfield_10003" would be your Sprint field and might have a different ID.

If you need help in creating your custom dynamic field, don't hesitate to get in touch with your support.

[Benjamin Dains]

@Nic Brough _Adaptavist_ I'm just curious if you know of a way to use ScriptRunner and make a scripted field for this? Or maybe Jira Automation?

[jan vasile]

I need the same for reporting and'or quick assessments of where everything is now - when I include the "Sprint" column on an issue list, I want it to show ONLY the current sprint assignment or blank, NOT several columns of every sprint that issue has ever been in. 

[Maurits Snijder]

I also face the same issue. Sometimes it's easy to export it to excel, because there may be some functions (like resource planning) that you want to perform in excel. 

It would be handy if you can export the latest sprint an issue is in straight to excel, so that you can later use a pivottable. 

Would be nice to have the field 'current sprint'

[P P]

So either I am misunderstanding the conclusion here or the conversation went sideways...

I think my problem is fairly similar:

I create a view of a list of issues with a specific filter that I want to re-use. Just to simplify the main thing what I am looking for:

I am filtering to a certain number of sprints (some are closed, one active, some are in the future). I want to create different dashboards (later power bi, but for now only in excel), where I can see how did the different teams perform in these already closed sprints, and how much is still left out of their team backlog. (all teams use the same Jira project, so technically there is only one big backlog, we are slicing it with different fields).

(So essentially one of the reports that I am trying to create is something similar to a Release burndown, but more custom and separate diagram per team.)

Within this view I am also showing the "Sprint" value, however unfortunately the Sprint value is not only the latest sprint value, but every other sprint values where the issue has ever been.

Problems with this on a report based on two simplified examples:

1) if a story was in sprint 1 then while closing sprint 1 we moved it to Sprint 2, then the exported Sprint value will be "Sprint 1, Sprint 2"

2) if a story was in Sprint 1 but then we decided that it will become out of the project scope for now, and let's say we moved it to Sprint 7, and my Jira issue filter only searches for stories in sprint 1 and sprint 2 and sprint 3... even then this particular story will end up in the report, doesn't matter that it's in Sprint 7 right now, but once it was in Sprint 1 back then so it's part of the report...

So the problem a bit is that while the Jira issue search view shows only the currently applied sprint value, the export already makes a concatenated string of "Sprint n" + ", " + "Sprint n+1" which results in me doing data cleanup every time when I export the view's content... At least in this case Jira doesn't create multiple columns, like in case of my custom label fields, because that's another nightmare...

[Jan Denny]

This is a legitimate problem needing a solution.

[Benjamin Dains]

Everyone, I have found a solution to this, but you will need Jira Automation to pull it off.

@jan vasile , @Tony Iuppa , @Vyas Thottathil , @P P , @Armstrong Shi , @Daniel Guerra , @Michael Brown , @Robert Prater 

HOW:

(1) Create an automation that looks for sprint value change, or how ever you would like to keep your fields in sync.

(2) Then run a check to make sure the sprint is active:

{{sprint.isActive}} equals true

(3) If the sprint is active, then write the sprint name into the, "Active Sprint" field.

Active Sprint = {{sprint.name}}

SCREENSHOT:

Sidenote: I always add to the audit log so I can see what values are being passed around, it makes life a lot simpler.

MORE INFO:

I used a read-only field so people couldn't change the value, and if you want to use the field in a JQL search it's as easy as:

"Active Sprint" is not EMPTY 

[Benjamin Dains]

I wanted to circle back and actually de-recommend this approach I typed out above. This worked most of the time, but when there were multiple sprints, it is impossible to tell the automation how to pick the correct one.

If I were to try and re-build it (the business no longer sees this as a requirement so it was descoped) I would look for a sprint event (sprint.start) and then grab that value and put it into the custom field to get current sprint, but all the issues outside of the sprint that are not there when the sprint is started will not have the right value.

We really need Atlassian to build this functionality rather than try and peace meal it together, there are too many single points of failure trying to make our own solutions without the proper coding possibilities (since automation is limited).

[Michael Brown]

Has anyone figured this out? Essentially I am trying to provide a report that reflects the view of the "back-log" to a client. They are not users nor SHOULD they be logging into our system.

.

I agree there should be the ability to query on issue.currentSprint-> sprintId, Rather than issue.sprints-> Array of SprintIds.

.

Again. Also, side note, can "community leaders" remember we are all here to help and keep it positive and not drag others. It's REALLY not necessary. If someone is asking a question then there is clearly a need, lets focus on answering those questions and educating on the system and process rather than typing down at someone. 

[Michael Brown]

Update:

Current Query

AND statusCategory in ("To Do", "In Progress") AND (Sprint in openSprints() OR Sprint in futureSprints() OR Sprint = EMPTY) ORDER BY Sprint

Workaround 1 - When you export, each sprint is listed in its OWN column. Kinda weird but easy for massaging the data, maybe a View Tab and "Source" Tab.

Workaround 2 - If you use the Microsoft Excell Jira Plugin, it results in a comma-delimited list for the sprints column. So easy to write a formula for it... and still maybe a View Tab and "Source" Tab like above

[Chrisjir Parkin]

My team has two kinds of issues that never close:

• Type 1 - issues that get moved from one sprint to the next
• Type 2 - issues that never leave the backlog

A simple filter showing multiple attributes (incl. sprint) for all unresolved issues finds

• Type 1 - anywhere there's a long sprint history
• Type 2 - anywhere there's no sprint and Created is long past

So what's the problem?

We need management-friendly results.  Managers want to know, "When will my need be met?"  They expect "the sprint" to show when their issue will close, a single object not a history.  Keep the existing sprint field.  It's fine.  We need a Jira field that shows the final sprint, or a simple JQL query to produce the same result.

The goal is to work in the dashboard, to display current data in a clear, concise display.  Realtime displays preclude document management, versioning, inaccurate metadata tags and multiple versions of the truth.

[Nic Brough -Adaptavist-]

You should change your processes so that you don't have either type of issue you've described.

Type 1 - you should be tracking non-sprint work somewhere outside the sprint.  These are not sprint-able items.

Type 2 - Actually, not so much of a problem, you could leave them in the backlog, but look at why they're never going to go into a sprint.  If it's because you're never going to do them, then be honest with your users - close them.

You should also have your managers go through a quick lesson on how Scrum works and what a Sprint is, so that they understand that they're looking at the wrong thing when asking "when will my need be met?"  (Sprints are not predictors of delivery, they're a timebox in which some stuff gets done)

[Chrisjir Parkin]

@Nic Brough -Adaptavist- 

People commit to completing what they pull into a sprint.  Sprints are a timebox in which people do the work they commit to doing.  There's a correlation between what's scoped for completion and what's completed.

There are many good reasons that sprint work may be left unfinished.  Plans change.  Emergencies happen.  Customers change the scope.  Testing reveals problems.  Any exception contributes to uncertainty in the amount of time it takes to deliver the committed tasks.

By measuring the time-averaged commit/complete ratio, the team becomes more and more adept at predicting what they can realistically deliver and how much time must be relegated to overhead functions.  Over time, teams will learn to do two things.  They'll learn to divide work into chunks (tasks) that can be accomplished within one sprint.  They'll learn not to create tasks that they can't accomplish.  These skills will increase the accuracy of their commitments to the point where a given sprint will reliably predict just how much work the team will accomplish.

Mature teams will build sprints that are highly correlated what they accomplish.

It would be really handy if, just for the visual convenience in reporting, Jira would show the list of tasks in the latest sprint without posting the entire sprint history.

[Nic Brough -Adaptavist-]

Um, yes, I already said most of that, and it's not relevant to the question, which is about the Sprint field recording all the sprints an issue has been in so that reports can work.

Jira can show you everything in an active sprint - just specify the sprint, or openSprints().

[Jan Denny]

I want to use the two-dimensional widget on a board, and want one of the dimensions to be sprint - but since Jira pulls in all sprints (not just the latest sprint), the same issue will appear on the widget multiple times - as many times as it was in a sprint. This throws off the count at the end. 

It doesn't matter how I define the filter criteria because an issue is in the widget, all its sprints will be counted. 

This could be a really useful view if the metrics weren't wrong. The metrics would be correct if the widget could instead use a field like "Latest Sprint" (even if it's in the future) as one of the dimensions.

[Armstrong Shi]

I am using a structure board to manage issues. I'd like to see the latest open or future sprints in which they are  rather than all closed sprints in which they were. In addition to Sprint, I also want to see other fields in the structure board. Rapid board does not support this.

Is that possible to add a column to show latest open/future/empty sprint in structure?

[jan vasile]

I wish Atlassian would fix this. I've been wanting it for years, and have requested in the past, but don't seem to get any traction from Atlassian on fixing this.  The additional column would save considerable time in manual adjustments, fit reporting formats, and make the reporting much more valuable to use in assessing where everything is NOW. I hope we hear some answers!

[Daniel Guerra]

same thing happens for me.  I just want to see the current sprint so they can be ordered by rank correctly in list view.

[Nic Brough -Adaptavist-]

What do you mean by "list view"?

[Daniel Guerra]

removing screenshots

[Nic Brough -Adaptavist-]

No, the field needs to contain the sprints, otherwise you destroy the information that it was in the sprint.

However, your reporting sounds wrong - this field's behaviour shouldn't matter.  I suspect your reporting is being done via an inappropriate route.  Could you explain what reports you are running and how you're using the sprint field to do it?

[antti_karvonen]

I have a similar problem: I want to list a bunch of Jira issues in a Confluence page. These issues are related to a certain customer, and then I would like to see the plan for these issues. The plan means in which sprint these tickets are planned to be resolved. I might have 10 tickets, some of them planned to a current running sprint, and the rest in next 3-4 sprints.

Then when I list these tickets, I would like to see just the latest sprint for each ticket, not the whole history. Therefore a column like "latest sprint", "current sprint" would resolve this need in an elegant way, without needing to change anything in current system behaviour.

With "latest sprint", "current sprint" I refer to a value to which sprint the related ticket is currently assigned to. Many tickets need to be postponed, and I do not want to see the history in this case, just the current value of this column.