I read a recent blog post where the author tried to explain why teams should never split "stories" (Product Backlog Items) during the Sprint. Unfortunately, the author used several Scrum myths and non-Scrum thinking in his arguments.
The reality is that Scrum teams should split user stories during the Sprint if it becomes clear that planned stories (called the "forecast" in the current Scrum Guide) cannot be completed to the team's definition of done.
I have worked with many teams that tell me they have rules against splitting stories during the Sprint. Sometimes they're organizationally-imposed rules. Sometimes, they're rules the team has imposed on itself. Often, the rationale has to do with "velocity" (the team's ability to turn Product Backlog Items into an increment of potentially releasable software)--somehow counting points is more important than delivery value! Other times, it's a misplaced "commitment"; that a forecast of the future (what can be completed by the end of the Sprint) is somehow a guarantee. In Scrum, we commit to the Sprint Goal not to some specific number of stories or velocity.
Using the spirit of Scrum and the Scrum Values, here are 5 reasons why you should split an unfinished story during a Sprint:
1. Get to DONE! Something done is better than the whole thing un-done. Stories that are not completed at the end of the Sprint go back to the Product Backlog so they can be prioritized by the Product Owner. Maybe the item is still important enough to continue in the next Sprint...and maybe not. If not, the team not only has no value delivered for that item, but it may be awhile before they can get back to it which will require re-work and maybe even starting over. Splitting the story so that some of the functionality can be completed (to the definition of done, of course) would allow some potential value to be delivered while the remainder of the functionality is returned to the Product Backlog to be worked another Sprint.
2. If you split the story during the Sprint, the team will better understand what you can actually get done instead of what you thought you could get done during planning. Going through the practice of splitting the story will also help the team better learn how to split Stories. It may even help them identify which ones are too big and need to be split in the future before planning.
3. Estimates for small items are more accurate than estimates for large items. People are better at estimating small efforts. By splitting stories that are too big to be completed, the team gains better insight into how much effort is really required for the functionality. That is, the sum of small estimates likely has less error that the estimate for one big effort. Getting more accurate right away is better than getting more accurate later.
4. It's a forecast, not a commitment. The July 2013 Scrum Guide stopped using "commitment" at Sprint Planning and Scrum now uses the word forecast. Forecasts are updated regularly...just like weather forecasts. Commitment is a Scrum value. Teams commit to the Sprint Goal, to each other, and to do the best they are able to do. Teams do not commit to complete a specific set of Product Backlog Items. They're trying to predict the future in a complex environment, after all. Forecasting the future is a more reasonable request than committing to it.
5. In Scrum, only the Sprint Goal is unchangeable throughout the Sprint. Everything else--the forecast of Product Backlog Items, how the work will be done, etc.--is negotiable! From the Scrum guide:
In order to satisfy the Sprint Goal, [the team] implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
And by the way, based on a conversation I had just today, let me clarify. Splitting stories during the Sprint means splitting them into one (or more) thin vertical slices; stories that are DONE to the definition of done. They are complete and in the potentially releasable increment at the end of the Sprint. They could be deployed into production, if the Product Owner agrees. I do not mean splitting stories because we finished coding and we'll test it next Sprint. That's waterfall! Don't do that.
Don't hesitate to split items during the Sprint if it helps you get truly done work this Sprint.
