Many Agile teams face a dilemma when picking up a new story towards the end of a Sprint. There is some time left but this time may not be enough to get a story done-done. An interesting discussion on the Scrum Development group tries to address this concern and find some answers.
According to Alan Shalloway, who started the discussion,
What'll happen if you half code something? You now have bleed-over (incomplete stories into the next sprint). If you already have bleed-over, adding to it is not a good idea and I'd rather the dev help close other stories that would otherwise bleed over into the next sprint. Work in process has a negative effect. We want to lower it and certainly not add to it.
The idea seems to be that instead of starting on a new story, more focus should be on completing the stories which are on verge of completion and would add business value.
Rob Park suggested that some unfinished stories rolling over from one sprint to the next might be a healthy sign. It would suggest that the team was working with consistent velocity. Zero work in progress could be an indication that the team is under-committing and has some amount of idle time towards the end of the sprint.
Jose M Beas added that if there is a story that can only be partially done during a sprint then it might be a good idea to break the story into smaller stories. This way, instead of keeping a large unfinished story a team can have smaller finished stories. A related post on InfoQ also suggested splitting the story into smaller stories as a viable option for treating unfinished stories.
Ron Jeffries added that, though he agreed that carrying over unfinished work might not be very helpful, however starting a story and carrying it to the next sprint is not very different from carrying an unfinished story over a weekend during the sprint. According to him, if there is not enough useful stuff that can be done towards the end of a sprint then starting on a new story might not be a bad idea.
Philip Cave echoed his thoughts on similar lines, according to him
Minimize WIP [Work in Progress], but we must have some WIP … any process must be seeded with just the right amount otherwise your "production line" comes to a standstill – AKA Standard Work In Process (SWIP).
One purpose for the time boxes in Agile is to create SWIP (to help manage our flow), another is to create short feedback loops with the customer (mistake proofing) … thus allowing us to define just the right amount of work and deliver value just in time.
Most Agilists on the discussion forum agreed that unfinished stories is a common reality than a rare event. During the sprint planning for the next sprint the story points for an unfinished story should be adjusted according to the amount of work left.
So what can be done towards the end of the Sprint instead of picking up a new story?
Using the time to write more test specs for upcoming stories, doing a little analysis, or cleaning up something that you've been meaning to do would be better.
Philip Cave suggested that the teams should ask relevant questions to themselves to manage their Standard work in progress, according to him
If we get close to the end of the cycle, and the story points for remaining stories tell us we do not have enough time to complete the story for this cycle that is when we ask … do we pull in another smaller story … do we schedule the review with the customer now … or do we pull in an "analysis" story preparing for the next cycle of work … or do we do something else …
Thus, the common message is that before starting a new story the team should evaluate various options which might add value. If the maximum value can be derived by starting a new story and carrying it over to the next sprint then the team should not be reluctant to take this path.