What's the ideal sprint length

Introduction

I may have blogged about this previously. I have written so many blogs, I can't recall any more. However 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 we 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 process, revealing any flaws. Like no automated build process, automated test harnesses our unit test frameworks. Fixing these flaws has a tendency to provide leaps in productivity gains for your organization. So assuming you buy the argument that shorter Sprints are better. My initial quick answer to the question is don't try to lengthen the Sprint. Rather try to figure out why you're only hitting 60% - 70% of your originally committed goals. By the way, 60% - 70% may not be that bad, after all you have a team that is currently demonstrating a consistent output Sprint after Sprint.

So that leads me to think that either the story point estimation is not consistent, or the team is just over-committing. So I would suggest that they do the following:

Try to really assess what is going on in the retrospective. Let team members speak freely about their thoughts on the matter. I would definitely spend a little bit of time re-assessing the size of a few completed 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 problem. Some folks, most notably Ron Jefferies, would argue why do you need to get your estimation down pat. Well in my opinion for one, predictability goes a long way to help remove team stress. So its great for a team to say we can commit to say 100 points and deliver between 90 and 110 each Sprint. The business will love you for this.

Whats good about this problem in and of itself is that Scrum is doing what it's 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. Many teams make it work so it should be doable. Hope this helps if you're in the same boat. If not at least if it provides food for thought!

Jack (agilebuddy)

Comments

[Martin Harris]

Probably one day longer than the spring length the team has chosen? :-)

Seriously though. I have worked in one and two week sprints and my favorite is the one week model. We found that there is less time for things to go astray, and the team has to demo at the end of each week. So you get more focus on the delivery.

I would have thought though the type of work also plays a part. If your building something where one week does not normally result in something to demo but two weeks would, two weeks has to be better.

[Jack Milunsky]

Thanks for pitching in Martin. I agree it most definitely depends on the context. And it's the team that can best make the decision but as a coach I'd urge teams to consider shorter to be better in the long run

Jack

[Wayne Allen]

When asked about the ideal sprint length I usually ask people "how far into the future can you see accurately?" Very few people can see past 2 weeks. Some can't see past tomorrow (usually because of some support responsibilities). This seems to be a good gut feel way to pick an initial sprint length and it makes sense to those who haven't been exposed to timeboxing.

[pariuri]

We run one we sprints at my company and as you stated it definitely stresses the systems in place. We know very quickly if something is not right and can address it. It has caused the "underestimated" argument to come up a few times, but usually we find it is an over commitment issue. We don't adjust the size of our sprints to accommodate not hitting our commitment, but we do lower the committed velocity to a more realistic and accurate number after about the 2nd or 3rd iteration.

[Mingus]

The restricting factor for my team has been how cumbersome we felt the sprint planning meeting should be. We are a quite large team ~8 people and planning three weeks work for 8 people was just too much so we became sloppy. When we got down to two weeks in sprint length, the sprint planning went much smoother. I think (but I'm not sure) that given the size of the team we have more overhead than a smaller team so going down to a shorter sprint length would cause the overhead to be proportionally too big.

[Pariuri Sportive]

sprint length selection has a strong influence on the work dynamics of the team. I think teams need to give careful consideration of sprint length give the type of work and the maturity level of the team.

[pariuri sportive]

Im really glad to be here on your site, because i`ve discovered usefull information for me. I`l be back with pleasure to read something new. Good luck and have a nice day .

[lili]

I love all your ratatouille ideas.

[casino online]

I am interested in this article. Please if you send me the email address more about this article? thanks

[poker online]

i love your articles youre always giving me great ideas on how to progress with my blog. thanks a lot for keeping us informed. i really appreciate all the essential knowledge you always provide us with =)

[pariuri sportive]

Can you give more details about this article?

[liga 1]

Superbe article, vraiment simple et utile. Bravo pour sa mise en ligne. C’est ce genre d’information que le public (et moi en particulier) recherche.