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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Carrying forward unfinished work in Sprints

The plan looks great. The team is on the same page. Your Product Owner is happy. But then it happens…

“We need to get this done, ASAP!”.

Your team is now in firefighting mode. And the plan that was once feasible, well, it’s not so feasible anymore. The only way to complete the original plan is to “get it done next Sprint”.

pasted image 0.png

If you find your team is moving unfinished work from Sprint to Sprint, here are a few suggestions of what to do instead:


1) Move it to the Product Backlog

First and foremost,

“When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.”

Mike Cohn

At the end of a Sprint, any unfinished work moves to the Product Backlog for the Product Owner to prioritise. It’s very likely a team will continue to work on this unfinished piece(s) of work, but it shouldn’t be assumed.

To do this in Jira:

  • Navigate to 'Active Sprints' and click 'Complete Sprint’.
  • Select ‘Move issues to the backlog’.

Screen Shot 2017-11-08 at 5.15.46 pm.png

2) Carry it forward to the next Sprint

If the unfinished work will be completed in the next Sprint, leave it untouched. But, if you’re using story points to estimate, only count points completed for the piece of work when it is completely finished in the next Sprint.

To replicate this in Jira, do the following:

  • Navigate to 'Active Sprints' and click 'Complete Sprint’.
  • Select ‘Move issues to the backlog’.
  • Drag the issue into the next Sprint.


3) Split and Plan for a Future Sprint

If the unfinished work will be deferred to a future Sprint, then create a new issue describing the subset of the work that will be delivered in the future Sprint.

If you’re using story points to estimate, you can count partial points for the original piece of work. For the new issue, as always, estimate it like you would anything else.

To get this going in Jira, you want to either:

  • Clone issue + adjust
    • Select […] > clone on the issue
    • Adjust the new issue accordingly 
  • New issue + move incomplete sub-tasks + link to old issue
    • Create a new issue
    • Using the ‘Link’ operation, link the new issue to the old issue.
  • Split
    • If you’re using Jira cloud or one of the latest server versions, you can right click an issue and ‘Split issue”.

Screen Shot 2017-11-08 at 5.17.01 pm.png


It’s natural for some work to spill over into future Sprints from time to time. It’s just one of many pitfalls teams face during their Sprints. Make sure to gather data, inspect and adapt and you’re team will be back up and running in no time.


Thanks for sharing

What JIRA server versions are required to split stories? I am on 7.6

Splitting is found by following the 3 dots > clone then ticking the split option.....

I am finding some aspects of JIRA quite aggravating in this space, and it seems that some of the issues are quite long-standing and still have not been fixed.

There are two big problems for me if I roll-over work to a new sprint (whether via the backlog or whatever):

1. In the new sprint, the Task Allocation summary (the ellipsis button) that shows the total work assigned to each developer, is computed on the the basis of the Original Time Estimate for the task, and not the Remaining Time on the task.

2. If I start the new sprint, the Burndown computes based on this Original Time Estimate (it would seem) and not from the Remaining Time.

So, let's say I have a developer Paul who has two one week tasks on his plate and they get one complete and the other task runs into some problems and therefore needs a couple of days on the next sprint to complete. The Remaining Time on the task is set at 2 days.

I rollover the task into my new Sprint, but the Task Allocation summary shows Paul has 5 days of work assigned to him. So that's unusable, now I need to basically jot the times down on a piece of paper.

And then when I start the sprint, the burndown graph assumes I am burning down from 5 days of work rather than 2 days of work, meaning our burndown shows more work to be done than my developers have working hours for.

Now the really crappy thing in this situation is that the only practical ways I can fix this are to either duplicate the task and fix up the estimates in each task, which just results in unnecessary noise, OR I edit the Original Estimate on the time, which kind of doesn't make it "Original" anymore, does it?

Anyone got any ideas for how to handle this?

Sure I know how to handle this! :-) 

Submit an issue to the Atlassian Support team, when they prioritize it after it's been voted on, they will select a release to add it to... If and ONLY IF, they're are enough votes.


More on that here ->


@Jabreal Johnson - are you sure about that?

388 votes...... entering its 16th year of request and still no closer. Better still, the last update from the 18th February last year states that it will be reviewed in 'about' 12 months time. I'll hedge my bets and say this won't see the light of day, this side of 2020.

If it's not going to ever get done - I just don't understand why they don't say so?

Like Brad Hunter likes this

@Kevin Frey  @Kevin Frey  Did you ever find a solution for what you described above? 

Some sort of bulk move from one sprint to another sprint would be very helpful without having to first move to the backlog.

This feature request has indeed sat unfinished in Atlassian’s weekly sprints, but at end of each sprint it gets moved to Backlog and then subsequently manually added back into the next sprint -- Rinse/repeat.  It's a vicious cycle.

Its all about hope ;) haha

I have faced this similar problem. But how about creating more subtasks if parent story gets moved to next sprint? For eg., having two 'Implementation' subtasks can be normal but make sure their Fix version is different (in our case a sprint is a new version. So this might not work for all). 


@Andrew Sand @Kevin Frey Allocating separate tasks to single developers and measuring how much of it they have accomplished during the sprint isn't Scrum och Sprints. It is classical (old-school) task allocation. If this is important to you, you should probably look at some other tool or Jira template.

Scrum assumes the team is working on all of its work and that it will try to finish them in the order they are in the backlog. Iff this is the case *and* the team knows its velocity (in terms of stories statisticaly being finished in a sprint) then you will sometimes get a story or two that has been started but not finished. This limits your work in progress to one or two items and the effort that it "steals" from the next sprint is limited.

In the case you allocate one task/story/issue per person then you get as many items in progress as you have persons and the chance of all of them being finished at the same time (at the end of the sprint) is very unlikely. This gives you a very high risk of much undone work at the end of the sprint, and all in different tasks, leading to a lot of the administration you describe.

So I'd say that the feature you are looking for is not there by design. But there probably are a lot of other ways, even using Jira, that could give you what you want, just not Scrum and Sprints.

@Thomas I'm not exactly sure how to consume your response to be honest. To paraphrase your conclusion it feels like you are essentially saying "Suck it up princess, you shouldn't have that many tasks rolling over to the next sprint anyway."

So, let's just accept that maybe we have a couple of tasks that roll over into the next sprint. Guess what? Now the problems I have complained about above come into play just as much as if I rolled over 20 tasks in a sprint. I have to manually compute Developer time because JIRA uses Original Time Estimate not remaining to advise developer utilisation, and the Burndown for the next sprint is still wrong.

JIRA's job is to make my life easier managing a sprint, and this behaviour does not make my life easier.

Like # people like this

When unfinished stories are moved to the backlog at sprint close, do they automatically go to the Top of the backlog ?

@Kevin Frey The same problem I'm dealing with. I exported data to excel to summary some reports, but I can't calculate the exact numbers because the Original estimates lasted in two or more Sprints.

Please assume that the developer is doing Task 1 at Sprint 1. Because of many reasons, Task 1 is not completed. My solution is to create Task 1 (phase 2) and rename Task 1 to Task 1 (phase 1) and change the status to Resolved. Based on this trick, I can calculate the developer's total time spent in Sprint 1.

Does it make sense to you?

Danno Community Leader May 13, 2021

Interesting to see other's have some of the same issues. We are trying Agile in a more traditonal hardware engineering company and have a software team that was using Jira beofre the rest of us had to come into the fold.

We typically have things go longer than one two week sprint. We let them migrate to the next sprint first and then decide if it stays in the next sprint or moves to the backlog before we start the next one. Most of the time it is because we don't break the work into small enough chunks and haven't gotten the hang of estimating difficulty especially since we try to have people estimate if it can be done within one sprint.

It sounds like to me that folks are assigning tickets that are too big for one sprint. If you're estimates are off, then re-evaluate your keystones. if it's too big, then break up the task into smaller increments. Clone and split as it says above if you need to. 

Like Sam Prince likes this


Log in or Sign up to comment

Atlassian Community Events