I wish all "In Progress" issues would be assigned to the current sprint. This would be a convenience when I choose to work on an issue that may not be part of a current sprint. The key advantage being that we use the Agile board "Work" section to view the current work efforts. It seems appropriate too that if someone is putting effort into an issue right now it is part of the current Sprint regardless if it was planned to be part of that sprint or not.
The whole point of sprint planning is that you decide what you are going to work on in this sprint.
If you bring something else into the sprint that you have NOT planned to do, then you are ignoring the planning. It should be a deliberate distinct action to pull other items into a sprint like that, because it should be infrequent and unusual, and it will show in your reports as a change of scope for the sprint.
If this is genuinely the way you work, that is absolutely fine, but you might as well dump the sprint planning element and go completely Kanban.
A bug on production pops up that changes the scope of the current sprint. I believe I understand your intent that we are modifying the scope of the sprint, but I'll admit we are not perfect at planning our sprints so we find ourselves adding issues during the sprint resulting in some issues not being completed at the end of the sprint and falling to the backlog. Honestly though, what got me to post this request was that I found 5 issues that have been "In Progress" for a long time that have gone unnoticed...nobody working on them. We mainly use the Agile Board instead of the Issues Search page filtering on Status. In Progress issues only appear in the middle swimlane of the Agile Work view of the current sprint so we never noticed them since they were not assigned to the current sprint. Perhaps the request should be to alert me when starting a new Sprint that "In Progress" issues are not part of the current sprint?
Your developers are not the people who should make the choice to change the sprint. "A bug crops up in production" - yes this happens. What you are supposed to do is plan it into the next sprint. If it's that critical a bug, then it can be drawn into the current sprint, but the choice to discard your planning needs to be made at a high level - it's not up to the developers just to whack it into in-progress and break your plans, it should be a choice by the project lead/scrum master and the whole team.
Ok, well, it still stands - you either plan sprints or you accept random work breaks it. With a small team, the communication about drawing things into a sprint is going to be easy, but if you're doing it a lot, you should consider dumping planning. Or if you're breaking plans a lot, split the work into two boards, one Scrum and one Kanban for the support/critical stuff.
Necroposting, because we have this exact request, and I can't find a way to do it in JIRA Cloud. Aaron, I feel you man. These comments are all well and good, but Aaron is asking for a way to customize his JIRA workflow, not a critique of his Agile process. JIRA should support the way we want to automate our work, whether or not it "breaks the rules" of Scrum.
So I'm still trying to find a way, for the convenience of my lead developer, to make an issue from the backlog that enters the "In Progress" status to be added to the current sprint automatically.
You won't get it natively, as it's not something you should do a lot. If you do find yourself doing it a lot, then you probably should simply dump scrum, as it's no use to you and move to using Kanban instead.
If you do it enough to justify the effort (but not enough to move to Kanban) you'll need code. It'll need to work out the current sprint, work out what the new rank should be and set it (do you insert at the top, or the bottom? Or maybe arbitrarily "always fourth down on the list"), and then update the sprint field with the selected sprint. As you're doing it on "moving to in progress", a post-function will do it.
I am not aware of any functions that can do this on Cloud, but I think the Script Runner might be able to craft such a post-function (it wasn't available for Cloud until recently, and I'm uncertain because I've not worked with in Cloud)
As for Atlassian incorporating it natively, I very much doubt it will ever be written in, for the reasons above. A tool built for Scrum is not going to be adapted to break Scrum.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot