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

Moving incomplete stories over to the next sprint

I am working with teams that are both new to SCRUM and new to JIRA and I am also new to JIRA.

We are trying to establish our velocity by estimating on JIRA. Most of the time, the stories are not completed within the sprint although we are getting better at estimating. When we move to the next sprint, we move the stories that are not in Done, to the next sprint.

The problem is that this skews both the previous sprint (which now reflects less work having been done than is true) and the current sprint (which now reflects more work having been done than is true) particularly when the tickets were almost complete.

What is the best way to handle this? 


I would argue that the statistics are not being skewed - they are a true reflection of which stories were or were not completed within the sprint.  Your target for sprint planning should be to allocate those stories which you expect to complete.  Over time, you should have less and less stories being moved to the next sprint as your estimating gets better (as you say it is).  For now though I think the reports are showing as they should, things were either completed or they weren't, there is no 'half done in sprint' concept with Scrum.

Like # people like this

Hi Pete


Thank you for your feedback. I agree with the sentiment of no half done in Scrum. Still, what do I do with these half done stories. If they go into a new sprint (whether it be the next sprint or a later sprint), half of the work is already done. So, if for example, we estimated it to take 5 hours (we use Fibonacci but just to make the point) and we already did 4 hours in the previous sprint and now complete the remaining hour in the current sprint, it looks like we completed 5 hours in the current sprint. Which we did not.

I don't know if there is a solve to this though.


Like # people like this

I don't think there's really a right answer, it's up to your personal preference.  You could reduce the estimate of the original, mark it as complete, then create a new story for the unfinished element.

There's a good article here:

Like Veera likes this

Atlassian have gone mostly for "standard" scrum - something that you told your product owner you were going to do is either done, or it is not.  A half-done story is not done, so it goes into the next sprint by default.

The "right answer" is, in Agile terms, to accept that while you might have got 99% of something done in sprint X, you did not deliver it, so it doesn't count.

The best way to handle this is to deal with that one thing that you didn't quite do in the next sprint.  Then use the retrospective to examine how you could have done it better, or managed to complete, or moved it out of the sprint so that your capacity was more accurate.

Like Veera likes this

@Nic Brough -Adaptavist- and @Pete Singleton 

Thank you for your comments. We already deal with the unfinished story in the way @Nic Brough -Adaptavist- mentions above. The question was more related to the following, which the article @Pete Singleton referenced answers here:



No.  You only burn down points on completed stories.  The "binary" approach your team is taken is not "drastic", it is what Scrum says.  (Any other way, and you're lying to your product owners)

Like Veera likes this

@Nic Brough -Adaptavist- - the image above it from the article referenced by @Pete Singleton - - not my words.

So I believe we are all on the same page. Thank you for your input.

Like Veera likes this


Log in or Sign up to comment