What is the best strategy to timebox sprints?

[Tai Nguyen]

We are still fairly new to Agile/Scrum development and trying to work out better processes while still being unobtrusive. One of the key concepts of Agile development which we really don't do well yet is timeboxing. This can refer to meetings but in this context I'm referring more to timeboxing the sprint itself. At our company, we run two week sprints. In the past, we have been letting sprints run until everything is done, which totally ruins our velocity reports. We'd like to start timeboxing sprints but I was wondering how other teams address the problem of partially completed stories. I'm thinking of creating a new story in the new sprint and moving over incomplete sub-tasks, but if we then mark the original story as complete, the velocity report will inaccurately show that we completed more points than we did. Do people update the original story's story point estimate to reflect how much of it was completed? Another approach would be to say that you should never split up a story into two sprints, since a story should always result in working, shippable code. In that scenario, we would move the entire story into the next sprint and not consider it done until it was completely finished. However, this also misrepresents the velocity report since some of the stories in the new sprint have a "headstart" from the previous sprint.

[Chris McFadden · Accepted solution]

In order to get any value out of the use of story points and velocity, the incomplete stories should be moved completely to the next Sprint. This is done automatically when you close a Sprint in Greenhopper. Any unresolved story will be placed on the backlog and you may/should include in the next sprint. The whole point is you only take credit when the story meets your definition of done. If you find that you are carrying over a lot of stories from Sprint to Sprint, you should consider taking in less and completing more, or having smaller stories. IMO, it is better to carry over stories that you did not start rather than a number of stories that are in progress. Limiting the number of stories in progress will help with completing more in the intended sprint, or at least minimize the carry over of partially complete stories. If you are using Git or Mercurial you may also consider using feature branches for stories so that only complete stories are merged in - that takes some of the sting out of the artificial sprint timebox boundaries. If you don't use feature branches, having partial work merged in to your default branch invalidates much of premise that you have a shippable product at the end of each Sprint.

By far the best explaination is in this blog post, but other books on story based estimating cover the same thing.

http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/

[Tai Nguyen]

Thanks for the insight, that actually makes a lot of sense. The blog post was also very informative.