When you assemble an agile Scrum Team, one of the critical decisions you make is the length of your iterations (aka Sprints). According to The Scrum Guide, the fixed length of a Sprint is “one month or less.” So, is there an ideal duration for an iteration?
One week
If your team is doing work to innovate and experiment, shorter feedback loops help discover what works and doesn’t. With this type of work, you want to fail fast, early, and cheaply. If you reach the end of an iteration only to learn that your idea isn’t feasible, you have only wasted one week’s worth of time, effort, and cost. Based on your learnings, you can quickly pivot to try another idea.
For short-term efforts or ones that are project- rather than product-based, 1-week Sprints could also be a good choice. When you have a brief, compressed timeframe to complete your work, more frequent, regular events are needed to communicate and deliver rapidly.
Two weeks
In my experience, this is the most common Sprint length that most teams choose. I think it’s the ideal length because it’s not too short, but it’s not too long to go without getting feedback (think Goldilocks).
Two-week Sprints also create a sense of urgency; 14 calendar days may sound like a lot, but it’s incredible how quickly time passes. I like to do a daily countdown with my Scrum Teams – it’s an excellent way to remind them that the clock is ticking on their timebox.
Three weeks
If your project is more complex or has multiple integration points or dependencies with external entities, a 3-week Sprint length might be the best choice. I have seen this work well for larger teams, where there is more to coordinate among team members.
My main hesitation with using this interval is that three weeks seems too long to go without showing work and getting feedback. The longer timebox may also cause people to get complacent rather than giving them a feeling of urgency.
One month
I have honestly never had any clients choose Sprints that last a month. I can’t think of a reason a team would select this option. With 1-month Sprints, you would only have 12 Sprint Reviews per year. That seems ridiculous to me, and I think there’s a higher likelihood that the team will go off in the wrong direction without the ability to make a fast course correction.
> 1 month?
I once had a client that was also working with another consulting company. I wasn’t involved in their project, but I was aware of it. They claimed to be operating in an agile fashion, but when I heard they had a 6-week long “Design Sprint,” I just about fell out of my chair. I couldn’t believe this firm (a massive, supposedly well-reputed organization) was doing so many things wrong.
I don’t consider anything longer than a month “agile.” Why “pretend” that you’re agile when you’re not? You might as well switch to waterfall because that’s usually what is happening, anyway.
Other
If you think about it, you could have day-long iterations or other increments that most people wouldn’t consider using. You might try this for a short duration when you need to learn as quickly as possible. It doesn’t mean you would have to keep that schedule, but if there’s a legitimate reason to do it, then why not?
Final Thoughts
I have found that two weeks is the ideal Sprint length for most types of work. However, some use cases may call for a shorter or longer duration – but be sure you never go more than one month.
What about you and your team? What is the length of your Sprints? Have you tried different timeboxes? What do you think the ideal length is? Why?