Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Add custom field with Sprints

We use Classic projects at Jira Cloud and my colleagues want to create new custom field, where they would be able to select one of our Sprints.
Yeah, I know, that there is a (main) Sprint field, but they want another one, just for their internal purposes.
Unfortunately, there is no possibility to add a Sprints field in Custom fields settings (only Releases, which is close)

Could smbd please advice me plugins or other methods to reach our goal?
I hadn't found any clear examples while googling.

2 answers

Hey there.

Today I looked thru tons of information on the forum. And I did few experiments.

What finally worked for me - the custom "sprint_bla_bla" field with type - Labels.

Thus, the custom field created was capable to save the "Sprint" field value/list which I did thru Jira automation rules for my needs  

0 votes

Hi @Dan

When you say another sprint field, what will it need to do?

Are they going to have an issue belong to multiple active sprints or multiple future sprints?

It's difficult to visualise the best app option without knowing more detail on how this would function - or suggest an alternative method of achieving your goal :)


Hey @Dan @Stephen Wright _Elabor8_  did you see any option to have the another custom Sprint field similar to default Sprint field. 

We also need to have two Sprint field on jira bug to track in which sprint the bug was found and the sprint when it was resolved. 

Is it possible to have the similar field with drop down options of sprint name?

Like davesoft11 likes this

Hi @Narendra Kumar 

Not that I know of.

There are two version fields - Affected Version and Fix Version, to show which release a bug was found in and when it was rectified. But not for Sprint.

In this instance I would use linked issues, and link the bug to the story/task which the bug relates to. That way you can see not just which sprint it was found in, but what functionality it blocks by not being fixed.


Like davesoft11 likes this

"In this instance I would use linked issues"

I like this idea since Issue Link types can be customized. But the problem is that the jira needs to be linked to a sprint / deployment.  We won't know the jira that caused the problem; but we'll know if a deployment broke it. 

Hi @davesoft11 

Sure - it isn't necessary to link to the specific Issue unless you can identify it, and there's a benefit to do so.

For example, if you're testing a specific Story for release and you locate a Bug, linking it back to the Story to show it is "blocked" might be beneficial.

But if you find a Bug in Production, there might not be as much benefit, unless the Production Bug has some inherent impact on something else (eg. a release cannot be completed due to a high urgency defect).


Suggest an answer

Log in or Sign up to answer