I am part of a development team that is relatively new to Scrum, suppose that at the end of the sprint a few large stories are either in progress or were not accepted by the PO.
Firstly, what happens with those user stories? Do you just carry them over into the next sprint?
If so, should they be re-estimated? In my view the work remaining on these user stories can be minimal or a lot? If not, why not?
EDIT: In my specific case, the stories were not completed because of an impediment that was a few days long, not because of user story underestimation. For those of you that it may help, we are using VersionOne
Best Answer
It depends. If no other story has a higher priority, then, yes, they are moved into the next sprint. If other stories have a higher priority, then they might be moved back into the product backlog if there is not enough room in the sprint to accomodate them. This all happens in the sprint planning, based on the priorities assigned to each story by your Product Owner. Since one of the purposes of agile methods like Scrum is to maximize the delivered value while reducing the time, it all comes down to how much value is added by finishing those stories.
Regardless of what happens, you still need to strive for a potentially shippable product at the end of the sprint. This might mean rolling back to ensure that the end-of-sprint product passes all tests and the completed features are fully usable by the user without any significant problems.
I would not reestimate because, in Scrum, you estimate a story when you accept it, begin work, and don't have a concept of partially complete. A story is either 100% complete, tested, and accepted (done) or it's not done. If there's no concept of partially complete, there's no way for you to determine how much work is remaining on the story. It appears that I'm not alone in this thought, either. You estimated the work that you thought you can do, so leave this data point in and make it a point to discuss why the estimate was off in your sprint postmortem and try to avoid making that mistake for future sprints.