We want to add more than one sprint name in a JIRA ticket. that is one JIRA ticket should be part of Sprint 26 and 27. So it has to be multi-select sprint
I'm looking for the same solution that add a jira ticket to multiple Sprints. The use case is in our company there are multiple group will create Sprint to manage the project. E.g.: R&D team, Program Team, ... A certian jira ticket will be tracked by multiple teams at the same time. It will be very help if we can track the same ticket in different Sprint board so that all the teams can track the status and on the same page.
I also would like to put a ticket into two differnt "sprints" - say sprint "v+ golive 1" and "se release 28". We do not use scrum, but our own framework, that has similarities to scrum and Jira is a good tool to support that.
But we have big projects (e.g. v+) and we have systems (e.g. se) which both have their "sprint-boards"...
btw: what could you recommend us as an alternative solution?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
It seems that it's wrong using of Scrum framework. A Jira ticket could belong only to one sprint.
So split your huge amount of work into two issues: Issue part 1 and Issue part 2. Put the first issue to Sprint 26 and the second to Sprint 27. Then you can create Epic and put two these issues to the epic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Or dont put the story in the sprint but put its subtasks in the sprint. This is more like the reality of things anyway. Tasks are work that is done during the sprint., Assigning the user story to the sprint just makes more work to manage issues (the same is true for Azure DevOps)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm trying to do the same was a Scrum sprint length is merely a suggestion, also, this works fine on a single-minded project but not on a multi project, multi projects could have sprints on different lengths, still same task tracked by two different projects/boards/teams.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tasks represent the actual work a single person does for a story in a sprint (a person can only be in one place at one time doing one thing). Tracking it as a predecessor or dependency in a different issue is fine, but the same task should not be on two different sprint team boards.
For ways to deal with multiple sprint teams in an org that may be using different sprint cycles, you may want to look into Scaled Agile Framework. It may have some techniques you can borrow for dealing with scenarios like you described.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tracking it as a predecessor or dependency in a different issue is fine
but the same task should not be on two different sprint team boards.
Perhaps I have mad a incorrect assumption, but duplicating a task and all the status and comment updates on it seams like needless work if we can just display the other teams task we are dependant on?
Is there perhaps a spacial type of ticket that copies another in-real-time that we could use just for dependancies? We could make a blank stub-ticket, and "link" the the dependancy ticket, but that seems like a workaround we would need to setup and take extra steps every time. Its not terrible, just feels like there is a better way.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree that there should be the ability to add issues to multiple sprints. For instance, we use XRAY for our test case management. I would like to show the testing being done for our QE department across our multiple projects, which the QE's straddle but currently there is no way to link a ticket to do this. So we're CONSTANTLY asked where we are on something when, if a test plan was on their board, they could just view it and stay updated. I know Dashboards would be the next option people suggest, but if that is out of the workflow norm for devs, data analysts, PO's etc they are not going to look there. They will just ask and slow down our process in doing it every ask.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't know whether this helps, but for anyone looking for this, you can force an issue to belong to multiple sprints (or remove something's history of having been in a past sprint) by using Bulk Edit, or at least this worked for me:
I'm not sure how this will work if you allow parallel sprints, but it at least works retroactively, like if an issue that was a part of a sprint was removed accidentally before the sprint was closed and this was noticed only afterwards. This approach is nice because it allows retroactively adding old sprints to issues without reopening those sprints. (Reopening sprints causes chaos anyhow, so IMO this method is better.)
Be aware that you can annihilate a lot of history this way, since this way you are SETTING the value of the array to the specific list of sprints provided, not just altering the last entry, like in other parts of Jira where you can set an issue's sprint. So, if you set an issue to be in two sprints and that issue had been in 3 different sprints before, you would lose its history of it having been on the third one. As such, this must be done carefully to make sure you don't destroy history you may wish to refer to later.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
An idea I used some years ago, now picked from vague memory, but perhaps useful for someone reading, trying to solve a similar issue: In the scrum board of project A we wanted to follow relevant issues in project B. We achieved this by adjusting the filter for the board in project A to also include certain issues from project B. You could use any set of fields as indicator, even a custom field. In our case I believe we used project ID (project B) + status (ongoing) + component (relevant to project A). This in addition to the criteria to include issues in current sprint of project A.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.