Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

One issue with multiple sprints

When we cannot finish the backlog in the current sprint, we would like to add it to the next sprint's backlog, right now if the issue is partially done with comments etc, we will need to clone the issue to the new sprint in order to avoid affecting the burndown chart, but this will lose the existing comments and logs unless I link it to the existing one, which is not very ideal.

2 answers

Hi James,

When you end a sprint, any incomplete or partially completed issues are moved to the next planned sprint. If you do not have a planned sprint, it is moved back to the backlog. There is no need to clone the issue again.

Hi Bhushan, when you move tickets to a newer sprint, it affects the burndown chart for the old sprint.

dRad Atlassian Team Feb 09, 2015

James- Velocity is the number of story points the team can fully complete in one iteration. When the sprint ends and stories aren't complete, the stories should not be counted in the team's velocity for that sprint. They should move to the backlog or the next iteration based on the product owner's direction. When the team completes that story in the next iteration, they get the full story point value in that iteration. One thing to look at is the team's definition of done which we talk about in sprint review: Also, if tasks are too large and frequently moving between sprints, it may be helpful to go to a further level of granularity in sprint planning. Having finer grained work will help make velocity more consistent.

Like # people like this

Related problem:
It appears that JIRA adds multiple sprints to an issue when it rolls over from sprint to sprint. For example if an issue could not be completed in Sprint 1 and is rolled over into Sprint 2, then JIRA adds Sprint 2 to the "Sprint" field of the issue while also retaining Sprint 1 in the Sprints field. If the issue again rolls over to Sprint 3, then JIRA also adds Sprint 3 as well to the "Sprint" field of the issue, so now the Sprint has 3 values. 

Implication: The same issue appears in Sprint Closure Reports for all the three sprints which is not correct and this messes up reporting.

Question: What is the "right" way to rollover issues so they do not appear in multiple sprints (drag & drop, close sprint) 

Like # people like this

We also have this issue, especially where issues cross projects and people don't have permissions to both projects. It gets very messy.

Whether the issues are moved to another existing or New Sprint the Sprint it was moved from, remains in the Sprint field. Even if you move it to the Backlog at the end of the sprint, it still leaves the previous Sprint name in the Sprint field, even when it sits in the Backlog.

Am I doing something wrong here? Using JIRA wrong? Understanding agile wrong? HELP!!!

You are doing nothing wrong. Unfortunately, it appears that Atlassian does not offer any way to get this visibility via queries.

Like Mouli likes this

I have the same issue as Rahul and it really disrupts our reporting. It doesn't make since to ever have a story in multiple sprints. For in progress stories, Jira correctly MOVES the item to the new sprint. But for stories in progress it ADDs the next sprint. This is inconsistent and should be fixed.

I am having the same answer. Was this ever resolved?

I'm having some problems with the Sprint field.

In the field, there is only the last sprint where the story is or was and not all the accumulated sprints that this story has been worked for.

Can someone help me?

I have nothing to offer, but you're not the only one. Some of my issues seem to retain all of the sprints, while others do not

Same here. An Issue with Type being task that is moved from one sprint to another retains the prior sprint information. Let's suppose that you have a Task that was in "Sprint 1", then got moved to "Sprint 2". When you run a filter, the column shows both Sprint names in the field on the screen, separated by a comma. What is interesting is that exporting the filter to a CSV file shows there are *two* columns, each with the identical Column Header name being "Sprint." In the first column, the Sprint is "Sprint 1";  in the second column the Sprint is "Sprint 2."

Guess what?  Suppose the Task subsequently moves to "Sprint 3." Now all 3 sprint names show up for the task, and there is *third* column in the CSV file!  Looks like this just continues and maybe this is a JIRA database constraint?

Please help. Having a Task showing up in multiple sprints throws off our dashboards and statistics.

I'm seeing a similar issue as well with cloned tasks inheriting the sprint value on the new task. I cannot remove the value from the new task, so it looks like it was not completed in the other sprint. To make it more confusing, the new task does not appear in the older Sprint report. Very odd behavior (Jira server 7.13.5).

Anyone heard of any updates for this or how to fix it / prevent it?

Oh no, no resolution on this? It's actually blocking my migration to cloud!

This can be solved by Bulk changing the ticket.

  1. create a 'Search' that finds the offending issue(s)
  2. select "Bulk Change" from the Tools drop down in the top right hand corner (look for the cog)
  3. on the edit page scroll down to "Sprint"
  4. Enter the sprint you'd like to use
    1. It needs the sprint ID,
    2. How do I find the Sprint ID? 
      1. go to the backlog:
      2. click the little blue hamburger menu on the sprint
      3. This should load a search query of tickets in the sprint.
      4. The Advanced Search query lists the ID
    3. Another way is if you can find the sprint listed as a hyperlink hovering over it will show you a URL with the Sprint ID
  5. Save the edit by pressing "Confirm"
  6. The sprint field now correctly lists a single sprint value.

You win.

Like David Maurizi likes this

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you