Thanks for reporting this issue. I've linked it to another one which is the same and has already been resolved (since JIRA Agile version 6.3.9). Please upgrade to the latest version of JIRA Agile to start using this feature!

Regards,
JIRA Agile Team

why not expose actions in the field, that would pretty much cover it

Not sure if this is duped by GHS-7573 or not, but we are running into this issue here.

Essentially, while we can find sprints based on name through JQL queries, we still have to do some rummaging to find a Sprint ID when we're trying to get a new issue into a sprint using the edit screens.

We don't mind using the Sprint field in edit screens for this purpose, but this disparity between the new JQL feature and this field is confusing for us.

If an 'Add to Sprint' feature is the prescribed method to get new issues into sprints, that's fine. However, since we don't typically have projects on more than one board, it would be nice if there were some under-the-hood logic to see if there's only one active sprint applicable to the project so this could become a one-click step instead of a two or three click step.

Thanks, guys! It's been nice to see some of the recent improvements to both Greenhopper and Jira, and I'm looking forward to see better integration of these two products in the future!

fixVersions are project specific so you can easily have an autocomplete feature that offers the right alternatives. Sprints are cross project, so unfortunately it's not quite that simple.

An 'Add to Sprint' button that then asked you to choose the board and sprint could be workable.

Cheers,
Shaun

I absolutely agree that these features should probably be changeable on a per-project basis. But for Operations or Support, creating a scope change is perfectly desireable. It means showing your manager how busy you were at the end of the sprint with interrupt work.

In our case everyone knows the sprint name (it's the Sunday date of the week) but I understand this won't always be true. That's why a button of "Add to Current Sprint" is desirable.

Right now, our process for any time someone opens a ticket is to Edit the ticket and change assignee, watchers, and sprint. If we could accomplish everything within this single step (without remembering a unique index value) that would be awesome.

Note: fixVersion is also a name with a unique index. Is this problem not solved by simply putting the same code in this field as in fixVersion ?

Hi Jo,

Thanks for your detailed reply, very helpful.

Just a quick question, it doesn't sound like the low level customer service staff could be expected to know your sprint name either. That is, they're not going to be able to add the ticket to your sprint themselves. Many teams at Atlassian deal with this case and to do so we use a quick filter for 'Recently Externally Logged' (that only picks up recent tickets logged outside the team), then just drag and drop the item in to the sprint.

An alternative way to do what you're trying to do slightly faster is to use the 'View in Agile Board' link from view issue then 's' and 't' to send the issue to the top, drag in to sprint. Still too many clicks but faster than the process you're currently using.

We will consider this in the future, but I'm a little hesitant because directly adding to the sprint in this way doesn't give the user a warning that they're introducing scope change. Still, I can see it would be useful.

Cheers,
Shaun

Several teams here work the way you expect: issues are assigned during sprint planning meetings. Growth doesn't happen much.

However, the QA, Client, Support, and Operations teams (which are all different projects) have new issues come up during the sprint which need resolved. In fact, it's not uncommon for the total time to deal with an issue and close it out to be ~5 minutes. The time spent on that issue needs to be shown in the sprint activity. This allows the burndown report to show how much time we spent working on planned projects versus bugs/interruptions.

In a perfect world, we would like an option for e-mail created tickets to be automatically added to the current sprint, but that's probably beyond the scope. When each of these teams receives an issue, they open it up and assign it to the current sprint and the person who will be working it. Right now, this means looking up an index number. No kidding, several of the teams have "CURRENT SPRINT = 29" etc on the whiteboards near them!!

Your expected model that low-level customer service staff would go into the Agile board and drag and drop the issue into the Sprint is unreasonable for the model.

For me, as a network engineer, I just got a major problem and I need to open the ticket and start progress and then GO DEAL WITH IT FAST. Taking time to switch to Agile mode, find the ticket at the bottom of the list (8 pages down), move it to the top so I can drag it over to the sprint... it's like 14 clicks and precious minutes of my life I want back

As for what it does to the sprint commitments: obviously the teams which grow tickets in the sprint are using Scrum mode. The general need is to show how bugs, emergencies, requests impact the deliverables. The sprint reports have been very useful in this regard. As of GreenHopper 6.0, this finally works pretty well. Well, except that fixVersion was easier to edit that Sprint is.

FWIW, this is the third company I've worked for in the last 5 years that uses JIRA in the same manner: operations and QA use JIRA so that we can set dependencies on developer work, create bugs for developers, etc. Likewise developers can set dependencies on JIRA projects, etc. JIRA really isn't optimal for operations use, but the ability to map issues back and forth is nice and GreenHopper 6 has improved this situation quite a bit. Features to auto-add new bugs to the active sprint, and buttons to do so in the interface, would go most of the way in making it very useful.

Hi Jo,

We are thinking of offering the ability to automatically add the issue to the sprint that is currently going (if you are creating the issue on a board and the board has an active sprint). We're trying to avoid direct entry of the sprint field, but eventually we'll probably support it.

Can I ask why you add items to an active sprint regularly? What types of issues come up? How do you deal with the effect on the sprint commitment?

Cheers,
Shaun

Um, no, that's really really not what I want. Having to go into Agile mode and drag the ticket around is way way way too cumbersome. That might work for Chris, but it is implausible for us. We really need to ability to add to current sprint easily, and not by remembering an index number.

Hi chrisem,

The Sprint field is not normally shown on the JIRA quick create or edit screen, your administrator has probably added it. You can use the 'Custom' link at the top right of the quick create screen to hide it.

Thanks,
Shaun