What is the best strategy to timebox sprints?

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.

1 answer

1 accepted

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/

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

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published May 21, 2018 in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

1,241 views 10 18
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you