In order to get any value out of the use of story points and velocity, the incomplete stories should be moved completely to the next Sprint. This is done automatically when you close a Sprint in Greenhopper. Any unresolved story will be placed on the backlog and you may/should include in the next sprint. The whole point is you only take credit when the story meets your definition of done. If you find that you are carrying over a lot of stories from Sprint to Sprint, you should consider taking in less and completing more, or having smaller stories. IMO, it is better to carry over stories that you did not start rather than a number of stories that are in progress. Limiting the number of stories in progress will help with completing more in the intended sprint, or at least minimize the carry over of partially complete stories. If you are using Git or Mercurial you may also consider using feature branches for stories so that only complete stories are merged in - that takes some of the sting out of the artificial sprint timebox boundaries. If you don't use feature branches, having partial work merged in to your default branch invalidates much of premise that you have a shippable product at the end of each Sprint.
By far the best explaination is in this blog post, but other books on story based estimating cover the same thing.
Welcome to your weekly Jira Ops Early Access program update, where we’re sharing news and updates on Jira Ops progress as we work toward our 1.0 release. If you ever want to drop us feedback or ideas...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs