Moving incomplete stories over to the next sprint

[Deleted user]

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? 

[Pete Singleton]

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.

[Deleted user]

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.

Thanks

[Pete Singleton]

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: https://medium.com/swlh/4-steps-to-manage-unfinished-stories-at-the-end-of-a-sprint-3b21edc16d55

[Nic Brough -Adaptavist-]

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.

[Deleted user]

@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:

[Nic Brough -Adaptavist-]

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)

[Deleted user]

@Nic Brough -Adaptavist- - the image above it from the article referenced by @Pete Singleton - https://medium.com/swlh/4-steps-to-manage-unfinished-stories-at-the-end-of-a-sprint-3b21edc16d55 - not my words.

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