The "ideal" sprint length
Many organisations today use Scrum as a framework for managing software projects and developing applications. As a certified ScrumMaster, I have been using Scrum for over five years and have seen it run in many different companies. When implemented correctly, I have seen that Scrum can be extremely successful. However, in the wrong hands, it also has its dark side and can cause devastation.
One of the things that I feel is an essential part in succeeding with Scrum is the length of a sprint. In this article, I am going to run through the different experiences that I have had with Scrum over the past 5 years and give some advice that might be able to help you out if you are beginning to implement Scrum in your organisation. These are my own experiences and by no means the law, and I am sure many Scrum purists might disagree!
A Sprint
Scrum is iteration based and generally work is completed and delivered in cycles of 2-4 weeks. This cycle is known as a Sprint and is meant to represent the “sprint” to complete the work.
During each sprint, a team creates a shippable product, no matter how basic that product is. Once the team has completed the sprint, they generally recuperate and plan for the next sprint. Each sprint cycle produces a constant rhythm and once a team is in this constant metronome pace, work should begin to flow in a timely and predictable fashion.
The Ideal Sprint Length
If you search Google for the "ideal sprint length" you will get varying results. Many people have different opinions on this and I truly believe that you should find the right balance for your organisation or project.
I generally have a few rules that I live by when determining the length of a sprint:
1 week sprints - I have found that these are not ideal. Sprint planning is a important vital part of Scrum and can take a few hours or a whole day. If you switch to one week sprints, you may find that you are constantly in sprint planning and lose a day of your sprint. This means you are only really left with 3 days of development with little time for QA. I have seen many projects spiral out of control when running against a one week sprint.
2/3 week sprints - The teams that I work with generally run between 2 to 3 week sprints. A full 3 weeks can sometimes be a little too long and may or may not fit in with your release cycles. I have generally found that around 2.5 week sprints work best for us.
If you are starting out with Scrum, you will need to find the right balance for your team and may find that you need to experiment with sprint lengths at first. Once you have established this "ideal" sprint length, the most important thing is that you stick to it.
Keep it constant
One of the rules that I live by when it comes to sprint lengths is that they should not be changed constantly. I cannot re-iterate this enough. A sprint is a cycle and begins to generate perpetual motion once a team is established. When a sprint doesn't quite complete and work isn't finished, the first thing that many people do is jump to the conclusion that the sprint length should change. At the first sign of a slipping project, I have often heard business colleagues say that we should change the sprint length to two weeks, and then to one week, and then back to three again.
The length of your sprint isn't that important, what is important is that you find what works and stick to it. Constantly changing sprint lengths sends a bad message to the team and the rest of the business. I have found that Scrum teams crave focus and a pattern in which to work, this familiarity creates confidence and builds momentum as the team matures.
When projects sometimes miss deadlines, think deeper about other causes and how you can improve next time before deciding whether or not to change the length of the sprint. You will often find that a good retrospective session will get to the cause of the problems. I have also previously blogged about the Five Why's and how this technique can be useful when determining the root cause of a problem.
If you are new to Scrum and Agile, I recommend this book, it's a great guide to getting up and running with loads of real world examples.
What are your experiences with the "ideal" sprint length?