Introduction

Questions regarding Sprint length surface on the forums regularly.
As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.



The Context

   A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.
There is proposal to increase the sprint duration to 15 days "because doing review meetings and planning every 10 days is a lot of overhead" according to the team.

My thoughts

   Let me start out by stating some facts ...
The official Scrum sprint length is 30 days. However I don't think (I don't have facts to back me up on this but it's the sense I get from all the communications on all the forums) there are many teams working to 30 days any more.

   Much of the Agile community agrees that shorter Sprints are better. So 2 week Sprints and even 1 week Sprints are becoming more the norm.

Why are shorter Sprints better?

   1. Well they have learned from the Lean folks that shorter Sprints means less work-in-progress which means shorter cycle times and overall less waste.


 2. Additionally, shorter Sprints tends to stress your method, revealing any flaws. Like no automated build method, automated check harnesses our unit check frameworks. Fixing these flaws has a twist to provide leaps in productivity gains for your organization.


 So assuming you buy the argument that shorter Sprints are better. My preliminary fast answer to the query is don't try to lengthen the Dash. try to figure out why you are only hitting 60% - 70% of your originally committed goals.


 Incidentally, 60% - 70% may not be that bad, after all you have a team that is currently demonstrating a consistent output Dash after Dash.
So that leads me to think that either the story point estimation is not consistent, or the team is over-committing. So I would recommend that they do the following.
Try to evaluate what is going on in the retrospective. Let team members speak freely about their thoughts on the matter.


 I would definitely spend a small little bit of time re-assessing the size of a few done items i.e. if the story was 10 points originally, what would they estimate the size now, after the fact. Re-assessing the relative size may well fix the issue.


 Some folks, most notably Ron Jefferies, would argue why do you need to get your estimation down pat. Well in my view for one, predictability goes a long way to help remove team stress. So its great for a team to say they can commit to say 100 points and deliver between 90 and 110 each Dash. The business will love you for this.


 Whats nice about this issue in and of itself is that Scrum is doing what it is supposed to do; surface issues for the team to resolve. And if the team feels that going to 15 day Sprints is the right thing to do, so be it - it might well be. But I would try to first figure out why 2 weeks is not cutting it. Lots of teams make it work so it ought to be doable.


 Hope this helps if you are in the same boat. If not at least if it provides food for thought!
View the Original article