Our Agile/Scrum teams are getting better at taking on manageable workload and completing them fully. However, sometimes for a variety of good reasons, some of the stories are not fully done at the end of the Sprint. Should we move or split these incomplete stories?
"Fail Early" with Product Owner Cooperation
If a team knows that stories will not be done by the end of the sprint, the first thing to do is talk to the Product Owner to see if the stories can be re-scoped or removed from the sprint without compromising the current Sprint Goal. This will enable the sprint to succeed even without 100% completion of the Sprint Backlog.
Splitting stories with the consent of the Product Owner is also an option. If a story is really composed of more than one user-visible feature, working with the Product Owner to tease out what part of the story can be done within the current sprint is a viable alternative to scrapping the whole story.
Once split, the stories would be done or not-done independent of one another. The trick, of course, is to make sure that the stories are actually independent, and that splitting them isn't just an elaborate accounting trick.
Disposition of Incomplete Stories
Any stories that are not-done at the end of the sprint receive zero credit. The sprint itself may still be declared a success so long as the Sprint Goal was met, but an incomplete story cannot receive partial credit.
Any incomplete stories are not automatically moved into the next sprint. Instead, they are placed back into the Product Backlog, where the Product Owner can re-prioritize the story based on lessons learned during the sprint.
For example, let's say you have a story about standing up a new MongoDB server. If the story wasn't completed during a sprint that was primarily focused on redesigning the login page, the following things should happen.
The point here is that user stories don't automatically move from sprint to sprint. Every return to Sprint Planning offers the Product Owner the opportunity to revisit the priority of items in the Product Backlog, and to make adjustments based on lessons learned or new strategic requirements.
From the Scrum point of view, it is cheating to make an incomplete user story done by cutting, changing, or modifying it. Actually nothing will happen if you have an unfinished story in your sprint, until you talk about this event during a retrospective and do something about it during the next sprint. The situation is a bit different if this user story must be in the final delivery. In this case, you'll need to consult the product owner and the customer.
Think about this as a signal: something can be improved. This is a good thing, because it is visible and manageable.