In our Agile/Scrum team, should we move or split incomplete stories?

Question

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?

Answer 1

"Fail Early" with Product Owner Cooperation

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?

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.

1. During the Sprint Retrospective, the team would discuss why the story encountered problems during the sprint. Perhaps a needed server didn't arrive in time, or it turned out that NoSQL was a bad design choice that should be changed.
2. The team hands the unfinished user story back to the Product Owner.
3. The Product Owner places the story into the Product Backlog if it remains important to him. He may also circular-file the story if it is no longer a feature he wants or needs.
4. If the story remains on the Product Backlog, the Product Owner re-prioritizes it against the other stories on the backlog, both new and old. The story may remain at the top of the backlog for the next sprint, or drop lower in the queue to make room for more urgent features.

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.

Answer 2

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.

Answer 3

I believe it depends on the nature of the story. If the story is comprised of tasks that are interrelated or clearly part of a well-defined whole, then the story should not be split if not done, and should be moved to a future sprint.

However, if the story contains tasks that are loosely coupled, such as a story for miscellaneous cleanup work or something like "make the interface more user-friendly", where the tasks are clearly self-contained and independently verifiable, then it can be very appropriate to split the story. Why not take credit for the work that is complete, tested, and can benefit the product, if other tasks that aren't dependencies are not complete?