Great news all,

As of the latest JIRA Agile version, you can now add issues to sprints in a number of ways.

• Right-clicking issues on Plan Mode to add them to a sprint
• Editing the Sprint field on an issue to add it to a sprint

More information on these methods is outlined in our documentation. Thanks for your votes and interest!

Regards,
JIRA Agile Team

I agree that GHS-7573 would be the ideal way to resolve this issue. Thanks for submitting that.

This would be a nice feature!

Why is this so hard to do. Let people have the workflows they want to work with.

I added a related issue (https://jira.atlassian.com/browse/GHS-7573), I think it solves it even better.

This is an even better (faster) sollution, but both would be nice

Why are you adding work to a sprint that is currently in progress?

In general, it is because during the sprint work was discovered that is of higher value to deliver than anything else being worked on in the sprint. It has been mentioned above, but generally this is either newly-discovered show-stopping bugs or issues that were newly-discovered to block development work already scheduled for the print. Secondarily this is from non-software development teams using GreenHopper. It happens every sprint, and I believe it is inherent to the type of software we develop and cannot be "disciplined" away.

nmuldoon

We also have a few reasons that we would like the ability to add work to the current sprint. Below are a few examples of situations where we would like to add work:

1. A bug created by other issues created within the current sprint
2. Creation of tests within the sprint for new bugs created within the current sprint
3. Creation of small cards for the developers (splitting of cards) due to deeper discovery of a story
4. A critical production bug that needs a patch

Our big two would be bugs and the creation of cards due to deeper discovery. We don't feel that this is adding scope, but rather it is just the natural addition of work as it is getting discovered. We do have rules around the creation of these type of items and sizing. If they get over a specific level then they are forced to the backlog for prioritization.

I believe that all of these options are within the Scrum Framework and are considered acceptable besides the production bug situation. We did try to have a separate Kanban style board for the production bug situation, but found it didn't get enough visibility since we only get a few of them. We also setup filters with email subscriptions... but in the end the teams found it much easier to bring them into the sprint from the support team and deal with them.

Respectfully,

Jeremy Neuharth | Founder
Sycorr

One small addition - now that there can be multiple concurrent sprints, this action should support it.

I would guess it would work similar to how the "Agile Board" action works for when the issue appears in multiple boards. So if there are multiple active sprints and you invoke "add to current sprint", you'd get prompted to select the sprint to add to. if there is only one active sprint, no dropdown is necessary.

A release for us is usually 5 one week sprints - 3 development, 2 QA (AKA hardening). We need to be able to add issues easily to the current sprint primarily during QA sprints, when bugs are found by QA and need to be immediately added to the current sprint for resolution by the developers.

Just to add to what Jo said, even engineers sometimes need to adjust sprint scope. Here are just three pretty common scenarios:

• we hit a critical bug in production, and we need to fix and push it quickly. it takes priority over other work in the sprint

• we scheduled a sizeable feature in the sprint, but after some initial work we hit a roadblock / external dependency that means we have to delay the work and put some new work in the sprint.

• for whatever reason, we weren't ready to point some work at planning time. we know roughly the work we plan to do, but need to do some investigation before being able to create and point detailed tasks. we want to do that mid-sprint after doing the investigation

for all these cases, while there is a way to do it currently with the dragging and dropping in plan mode, it would just simplify the workflow greatly to be able to do it right from the issue view.

The core problem here is that you are trying to force every team that uses JIRA to operate the way you think a developer team should operate. The reason this doesn't work is that many companies have other teams use JIRA to enable cross-team tracking of ongoing issues. Some of the other teams that use JIRA are not scope constrained, and fully expect to receive interrupt work during their sprint. The company likes to see the amount of project work versus interrupt work performed during the sprint broken down in the burndown report.

In essence, what I am saying is that for some teams, scope change is expected and tracking of the scope change is desired. And for most of these teams, a project manager is not involved in every scope change.

I'm reposting my comments from over on GHS-6459 because I believe they answer your questions: Drawing just from $CURRENT_EMPLOYER, 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 as little as 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 scope and 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. The value provided by the scope change within the sprint is to show the management team how much interrupt happened during the sprint, and why the commitments for project deliverables were not met. As of GreenHopper 6.0, this finally works pretty well.

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