Dear all: Please vote for GHS-10651 which fixes the same problem in the Bulk Edit feature.

chl, please follow this issue: https://jira.atlassian.com/browse/GHS-7255

We just upgraded,work good.

It would be nice if you could use the field in basic mode in issue search. Maybe you have plans for that later?

I forgot: Happy birthday, dear issue
Even better today: Happy: you got solved

We are pleased to announce that this issue has now been resolved in JIRA Agile version 6.3.9 which is now available to download.
https://confluence.atlassian.com/display/AGILE/JIRA+Agile+6.3.9+Release+Notes

Thank-you for your feedback and votes on this issue.
Kind regards
Martin
JIRA Agile team

Hi All,

Many thanks for your feedback and votes on this issue, I wanted to provide an update for you: we have now scheduled work on this and aim to get it to you within a month or so. I will update this issue again once the fix is available for download.

Kind regards
Tom Kotecki
Product Manager, JIRA Agile

It really is unacceptable that people must figure out the sprint ID, both because of the extra time, labor, and attention, and because of the high error rate. We name our sprints so they make sense to people, rather than forcing our people to adapt to JIRA. We need this ability when editing individual issues and when making bulk changes. This feature's absence combines with the inability to suppress email notifications of sprint assignment changes (except when bulk editing) to result in email bombardment. Those two deficiencies make it difficult for us to convince more teams to use JIRA.

@Ben - If sprint field is present on your edit screen, than you can edit the sprint using structure, (alas, you have to key in the sprint id, but hey I'm training my memory every day! )

Agree with the comments here, unbelievable that the issue still not resolved.
I have to 'defend' Jira before my colleagues, saying, yeah, they wanted people to assign issues to sprints using JiraAgile and not issue Create/Edit... that's quite time wasting...
What would be really great is to have 2 things in the issue Edit form:

• Choose Sprint by Sprint name
• Use a combobox to choose : send to top of the sprint, send to the botom of the sprint. - These are really two most common scenarios!

Right now (seriously) they're writing their team's current/past Sprint Numbers on post-its attached to their screens so they can do this

We do the exact same thing, tester, managers, dev and all.

Don't seem like a minor thing that whole companies have post-it with numbers to workaround your software?

And yes it seems like it is a copy paste. From the issue search field to sprint field. (as a user and dev.)

..within the next 12 months..

I guess this issue will have a one year birthday, maybe two?

Hi Tom,

Good list of use cases, I'd offer a couple of comments:

#1 - I actually need to find issues which belong to a dynamic set of Sprints, not just a single one or two. We have 8-10 teams working on different Sprints, but they all name their Sprints follow a numbering convention (e.g. "Team A Sprint 56" through "Team J Sprint 56") and in JQL I'd like to grab everything following a pattern, i.e. any Sprint with "Sprint 56" in its name. This gathering of a set of teams' work is useful for reporting at an across-Engineering level.

#4 - may be challenging, but honestly that's a very frequent use case by our devs - they'll Create an issue from anywhere and want to drop it into their current Sprint without going to any other screens. Right now (seriously) they're writing their team's current/past Sprint Numbers on post-its attached to their screens so they can do this - a pretty big dissatisfier. (Jumping to a solution, note that 99.9% of a dev's work is in the same Board at any given time, so just suggesting open Sprints from whichever Board they used last would probably work for the vast majority)

Hi Tom,

Thanks for the update.

An angle I don't see covered is: How do I bulk edit issues from a filter into a sprint? Say that we'd like to plan a patch to address any lingering beta issues: I can filter for our beta label and then bulk edit using the enumerated sprint ID, but I'd much rather bulk edit and start typing the sprint name than have to scramble for the sprint ID (especially if there aren't any issues in the sprint I just made).

I don't want to drag and drop stuff or click context menus from the Jira Agile interface (though I appreciate how easy it is to do stuff here). I want to utilize the flexibility of issue filters to find the things that I want in a sprint.

If the sprint names are retrievable for the dynamic text that facilitates writing the JQL, why aren't they available for the Sprint edit box on issues? From an end user perspective, it seems like a short missing connection that causes some grumbles from all of my staff whenever they run into it. And sometimes we run into this during a planning meeting, which makes them feel longer because we have our team in the room watching someone drive Jira instead of planning our thing.

Hi All,

Many thanks for your feedback and votes on this issue. You're right that it wasn't entirely covered by the other issues I mentioned.

There are four distinct use cases I can see here:

1. How do I find out issues which belong to a given sprint with JQL - this is the one that is covered already: you can simply type "sprint = " and either choose a sprint from the autocomplete list, or simply leave the sprint name in quotes, e.g. 'sprint = "Sprint 2"'.

2. How do I easily add an issue to a sprint on a board, without having to drag it all the way to the right sprint - you can easily achieve that by using right-click context menu (which even works when multiple issues are selected).

3. How do I add an issue to a sprint after creating it (e.g. a QA finds a bug and wants to add it to the currently running sprint) - this is covered by https://jira.atlassian.com/browse/GHS-6866; we are working on a solution to this scenario and should have it available for you very soon.

4. Lastly, how do I put an issue to a sprint from JIRA Issue Detail view - this is the remaining bit, covering all the other cases. Given current JIRA architecture, it's computationally very expensive to find out which sprints are relevant for a given issue (i.e. you wouldn't want to see all available sprints in your instance if the issue at hand will not be displayed on most boards in the first place). We do plan to solve this, though, by adding a button which will allow you to trigger this action. We aim to deliver this to you within the next 12 months.

Kind regards

Tom Kotecki
Product Manager, JIRA Agile

How is this "Minor" priority? This is a major issue, possibly critical.

I am facing an issue where we get resistance from PM's for adopting scrum board.
They are used to the ease of using 'fixVersions' to prioritize and manage a set of tickets.
A feature that offers the same ease of use, but with Sprints is desired.

For our product we have over 1000 + tickets on our backlog, and 20-30 unstarted sprints for various programs of work.
In addition we use con-current sprints on a single rapid board. This is all to ensure a single and consistent landing page for staff to work from.

Whilst the planning board is great for planning, and the work board is great for standups, the current system does not support quickly scheduling work directly from the issue.
A typical use case is:

1. PM gets e-mail due to being assigned the issue, or due to a mention in a comment...
2. PM opens the ticket from the e-mail
3. PM wants to schedule the ticket, so usually just sets the fix version, and later goes through all issues in that fix version during scoping/planning meetings
   With green hopper the user has to trawl through a massive backlog and drag the ticket through umpteen un-organised sprints.

That is some of the same problem we have Marc. But we are changing. If there are bugs in a feature we are doing in the sprint then the task for the feature should be set as reopened. Because it was not solved. If the bug is found i a later system test, then it should be planed for a later sprint.

As we have a live product that is never ending, we do have live bug that are critical and should be fixed immediately. These we would like to add to the sprint running. Might not be the scrum way, so this might also be us that are holding it wrong.

Completely agree. Adding (at least) bug-type issues to the current sprint is in our (I think most) organisation a tester decision (depending on how blocking the bug is for demonstrating one of the User stories in the sprint). But a tester normally do NOT use the Plan mode, they do not 'plan' sprints. Therefor this 'limitation () is realy blocking for us! SO PLEASE ATLASSIAN CHANGE THE PRIORITY (or explain me what priority minor is mening )

This is a huge dissatisfier for our team, it really diminishes their view of JIRA when having to type in index numbers (and it's highly error-prone). While it may not be the way you'd ideally want them to work, many people work in the classic issue view environment and don't want to have to keep going back to the Agile views just to move something from one Sprint to another. (Great work in 6.2.2 making Epic relationships editable by name, now let's extend that to Sprints and my folks will be super-happy!)

Go Atlassian go.... We are still waiting for this.

It would speed things up in our end, if we did not to have to remember an id in the database for the sprint.

I'd like to point out to others that I've asked for a feature that is the real fix for all of us that are using the Agile stuff in an Operations or Support team. It's GHS-8182, which if we can convince them to implement would in a single punch solve this problem.

tkotecki or ckimloong can you please review this story and reopen - it has been misidentified as a dup. I'm happy to elaborate if the previous comments aren't sufficient. Thank you.

Does anyone know if we need to create a new issue to get a response from Atlassian? I don't see a way to reopen this and I haven't seen a response from them since Christen's question 2 weeks ago.

Can someone from Atlassian please clarify whether the change for GHS-4949 will also allow us to add items to sprints from the issue page (or any other form that can contain the sprint field) using the name, rather than the sprint ID?

I agree with Erik. We have the same problem. There are times that I want to create an issue and assign it to a sprint on the spot.

This is not a dup request of GHS-4949 or GHS-5773. I think this issue is asking for:

1) While creating an issue in JIRA, you can assign the to the Sprint name directly
2) While editing an issue in JIRA, you can assign or reassign the Sprint name directly.

Today you can only do this by knowing the Sprint number, or by going to the Rapid Board as a second step.

My company has just implemented Greenhopper and this is a big stumbling block for acceptance.

What do you mean by it is covered. Because the other issues are jql searches, not typing into fields when creating updating issues. But this might be done while fixing these issues?

This is covered by GHS-4949 (now implemented) and GHS-5773.

Just some ekstra info to the issue, copyed from another post:

The point is tiresome workflows, here is a case where we find a bug and need to add it to the current sprint (it could also be when we are planning a sprint, and we are breaking up stories, we add a lot of new issues to a sprint in planning).
Current workflow:
1. Create issue (bug)
2. Go to planning view in rapid boards
3. Find the new issue somehow, usually browsers find field and remembering the issue number
4. Right click the issue and say move to sprint XX
(That is a lot of clicks and time used)

We wish for a workflow like this:
1. Create issue (and write the name of the sprint, system auto completes it, like label and fixVersion)

Second case: I have an issue/story/bug that is descoped from the current sprint to the following sprint
Current workflow:
1. Go to planning view
2. Find the new issue somehow, usually browsers find field and remembering the issue number
3. Right click remove from sprint
4. Find it in the backlog
5. Right click add it to next sprint in planning

We wish for a workflow like this:
1. Go into the issue (usualy we are already there)
2. Edit (and write the name of the sprint, system auto completes it, like label and fixVersion)

I don't know if you get it, but for us, using your system, it is a big problem. Taking time and is a cause for mistakes.

just to clearify: Make it work the same way as labels or fixVersion. You start typing, it autocompletes (both planning og started sprint in the same input box) that would be nice.

How is this minor?! In what imaginary world do QA not find any bugs for the current sprint? Please Jira, change the priority of this issue and please address this glaring oversight.

Also include that it can be added to several sprints at the same time.

It would also be nice to be able to add the issue to sprint(s) in planning (uses a different field). So when you are creating new issues you can add them directly to the sprint(s) that you are planning.

One click one buy. (The way to do it now is: add issue, navigate to planning mode, find issue, move it to sprint. Thats at least 4 clicks)