The optimal sprint length has always been a discussion-provoking topic.
Although there seems to be a general consensus that two-week sprints are the way to go — or, at least, every company or client I’ve worked for has adopted a biweekly cadence — there’s no guarantee this is the most appropriate length for a given context.
Your work cadence tremendously impacts your day-to-day work, and it’s not only about meetings. For some reason, I’ve always found the ideal sprint length a fascinating topic and thus have experimented heavily throughout my career.
In this article, I’ll summarize my various sprint-length experiments, what they taught me, and the key takeaways. I hope they’ll inspire you to experiment with your own process.
Table of contents
- Experimenting with sprint length
- Standard, two-week sprints
- One-week sprints
- One-day sprints
- Three-week sprints
- Lessons learned
Experimenting with sprint length
I’ve experimented with changing sprint length roughly 15 times in my career. I ran these experiments in various contexts:
- Within small and established companies
- Working both in-house and in a software house environment
- With discovery- and delivery-focused teams
These experiments enabled me to understand the various tradeoffs and consequences of different sprint cadences and helped me develop a framework for choosing the right length.
Without any further ado, let’s dig in.
Standard, two-week sprints
I call these “standard” sprints because, based on my experience, most companies operate on a biweekly sprint basis.
The point of the standard two-week sprint is to balance the overhead of regular scrum ceremonies and provide the team enough focused time without compromising planning flexibility. This often works, but it’s far from a silver bullet. While running biweekly sprints in various setups, I’ve noticed a few recurring patterns:
- Balanced overhead
- Struggles in a dynamic environment
- Sprint goals become unfocused
- Biweekly retros delay learning
Balanced overhead
The fundamental basis for biweekly sprints — that they balance the number of meetings — seems to be true in most cases. If organized well, it gives you a whole week free of scrum meetings other than dailies, and it’s a blessing for both the team and the product manager.
Struggles in a dynamic environment
Two weeks is longer than you think. New opportunities appear on a weekly basis, and while we shouldn’t chase every new shiny object, often, these opportunities are actually worth pivoting toward.
Whether it’s because we learned something new or finally got approval/sign-off for an initiative one day after sprint planning, parking an idea for two weeks might not make sense. In my experience, it often results in re-planning a few days after the start of the sprint, adding more overhead and distraction.
Sprint goals become unfocused
This is especially common for larger teams. The idea behind the sprint goal is to give the team a shared objective for the sprint. But what if these can be achieved within a week or so?
Learn more →We often ended up reaching our goal mid-sprint and switching to another goal, which killed the idea of a “single objective.”
Biweekly retros delay learning
I’ve noticed that team members often resort to a “let’s cover it on retro” mindset when issues arise. It’s easy to write that off as a culture problem, but let’s take a reality check: with busy calendars and goals, it’s easy to say, “I don’t have time for that today. I’ll cover it in our retro in four days.” By then, these topics are often outdated or we simply forget about them.
1-week sprints
Weekly sprints have always been tempting to me. They come with a promise of better predictability and faster learning and iterations.
Today, weekly sprints are usually my go-to format for brand new teams. The idea is that, if we plan and inspect our work every week, we can learn faster and go through the forming and storming phases of team building quickly.
But as you can expect, the world is rarely black and white. Here’s what I learned by experimenting with one-week sprints:
- The ‘faster learning’ premise never worked as expected
- Planning and estimating became more accurate
- Small issues caused big problems
- Same velocity, higher overhead
- More stress
The ‘faster learning’ premise never worked as expected
Although weekly retros do give more formal opportunities to inspect and adapt, the shorter timebox and higher frequency are sometimes counterproductive.
On the one hand, weekly retrospectives made us work on more atomic, up-to-date problems, and fewer things slipped through the cracks. On the other hand, they always seemed shallow, as if the problems never had enough time to become painful enough for team members to act.
Shorter timeboxes also reduced our ability to go deep. Some challenges were big enough that we couldn’t solve them within a week, so we had many open loops and revisited the same topics.
Overall, the pros and cons of weekly retros usually balanced themselves out.
More great articles from LogRocket:
- How to implement issue management to improve your product
- 8 ways to reduce cycle time and build a better product
- What is a PERT chart and how to make one
- Discover how to use behavioral analytics to create a great product experience
- Explore six tried and true product management frameworks you should know
- Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Planning and estimating became more accurate
The most significant advantage of weekly sprints was their planning accuracy. Estimating our capacity for a week is just less problematic and more manageable. Keeping weekly commitments is easier, and it provides welcome short-term predictability.
Small issues caused big problems
One team member calling out sick, one unplanned workshop, one partner outage, and your whole sprint goal is kaput.
With weekly sprints, just a single day off reduces a team member’s capacity by 20 percent. Unexpected events simply hurt more the shorter the sprint.
Same velocity, higher overhead
In theory, shortening all timeboxes by half should lead to the same overhead. In practice, it does the opposite. One 90-minute long meeting is often less disruptive than two 45-minute long meetings.
You probably know the feeling where you have five minutes before the next meeting, so you don’t pick up anything new and just brew yourself another coffee. Weekly sprints, in my experiments, almost doubled these situations.
More stress
This might be a personal thing, but the weekly cadence put more stress on my mind than when we were running standard, two-week sprints. I had to worry every week about how the next retro would turn out, how to nail the next review, and what sprint goal would be the most optimal. There are no “chill weeks” when every week is sprint opening/closing week.
1-day sprints
This was a wild experiment. I tried single-day sprints twice, actually. Maybe I’m a masochist.
I tried this approach during a time when our direction was in flux. It was impossible to plan for three days ahead, let alone a week or two.
In both cases, the approach was the same: one “scrum festival” meeting every day. We tried to pack the following daily, 25-minute sessions:
- Review — 5 minutes
- Retro — 10 minutes
- Planning — 10 minutes
These experiments were super fun, and I encourage you to try them out sometime. It’s an eye-opening exercise, if nothing else. Here’s what I learned:
- Ceremonies got skipped
- Many improvements equal shallow improvements
- ‘Ready for QA’ became our mantra
- Cycle time was optimized
- The expirment died a natural death
Ceremonies got skipped
We quickly started skipping retros because there was nothing to discuss, and reviews turned into irregular, ad-hoc sessions. Sometimes, we didn’t have anything new to show after one day, and sometimes, it was hard to get the time from essential stakeholders.
Many improvements equal shallow improvements
Covering the retrospective part almost daily was a double-edged sword. On the one hand, the new improvements we introduced and challenges we solved were impressive. On the other hand, we always missed root cause analysis and covering bigger, fundamental issues.
Ultimately, I believe daily retrospectives are good exercises to run every now and then with any team to grab any low-hanging fruit, but it doesn’t cover fundamentals.
‘Ready for QA’ became our mantra
Developing, code reviewing, and testing tickets within a single day was challenging. We ended every “sprint” with tickets in QA because we simply didn’t have enough time to test it.
Cycle time was optimized
The best part of daily sprints was how they forced us to improve our processes. There was no longer time to wait two days for code review or a week for the designer’s review.
Although there’s a limit to how fast the cycle time can be, it did help us eliminate a lot of inefficiencies and build a more disciplined culture as a team. The pressure was somewhat unhealthy, but also very beneficial.
The experiment died a natural death
Both experiments ended similarly. At some point, we decided we wanted to hold deep-dive retros every now and then, so we added them to the schedule as an extra meeting.
Then, we figured out we needed external reviews in a more sustainable cadence for stakeholders, so we added yet another meeting. We also needed a long-term vision for more effective refinements.
Ultimately, our scrum festival naturally evolved back to daily meetings with supporting meetings every week or two. Unconsciously, we went back to biweekly sprints.
3-week sprints
I once worked in a yearly roadmap-driven corporate setup, where we had a clear scope for almost a half year ahead. With the assumption of lower overhead with less risk (our plans rarely changed), we tried out 3-week sprints.
Here are my takeaways from that experience:
Infrequent retros sped up our learning
I felt like we found the sweet spot for our retros. With a formal retrospective every three weeks, we were less likely to fall into the “let’s wait until retro to bring it up” mentality and had more ad-hoc mini-retros and problem-solving sessions.
Surprisingly, the frequency of our inspect-and-adapt cycle actually increased.
More focus comes at a cost
Having two weeks in a row without any ceremonies was promising, and to an extent, it worked. But these weren’t fully focused weeks.
When planning and refining for three weeks ahead, it was easy to miss some details or leave some third-week scope refinement for later.
So, instead of planned, structured sessions to review work and plan details, they happened ad hoc. But we also learned we don’t always need half of the team to run a proper refinement session; sometimes a huddle between two developers is enough.
Predictability is critical
While three-week sprints worked fine with a stable roadmap, it stopped working when our roadmap started shifting. Sometimes, it was a business change. Sometimes, it was due to a third-party delay. Mid-sprint replanning became so frequent that they killed the idea of longer sprints.
Lessons learned
Each experiment gave us a unique set of lessons. If I were to summarize them into two general buckets, they would be:
Factors that influence optimal sprint length
From a time perspective, two things that had the biggest impact on the success of various cadences were:
- Cycle time
- Predictability
Let’s visualize it on an XY axis:
Cycle time determines how fast you can move a work item from “to do” to “done.” The lower your cycle time, the shorter sprints you can afford.
For example, if it currently takes you five days to develop, review, and test one Jira ticket properly, then weekly sprints likely don’t make sense, because that would mean you won’t complete anything you start on day two of a sprint.
Predictability is also a key factor. The longer sprint worked like magic, as long as our scope and roadmap were predictable. If you can confidently plan work for a month ahead, why not do so? But if you have problems securing a stable scope of a week ahead, then two-week sprints are already doomed.
The chart is just an overall guide. There are many other factors influencing the optimal sprint length, but I believe that predictability and cycle time are the most essential ones.
It’s OK to break the rules
The Scrum Guide imposes artificial rules for sprint ceremonies, including that they should happen every sprint. Yet, the more we experimented, the more we learned that these rules only limit us. Working on daily, weekly, or three-week sprints often forced us to bend the rules, and we rarely regretted it.
Regardless of your sprint length, if a rule or principle annoys you, just break it.
Are you currently running monthly sprints, and you love it but feel that retrospectives are too rare? Don’t adjust the sprint length. Hold mid-sprint retrospectives. I promise, Ken Schwaber won’t visit you in your sleep if you do.
One of my teams currently runs weekly sprints but holds biweekly retros. It simply works for us better.
On another occasion, we had weekly sprints but held biweekly planning. We planned in detail the sprint ahead and preplanned the next sprint to give the team a sense of direction and help them refine ahead of time. After a week, we revisited the plan for the upcoming sprint while preplanning the next one.
Pre-planning might not be part of classic scrum, but we focus on what works best for us, not what’s in the books. I would encourage you to experiment and find a rhythm that works for you.
Closing thoughts
Sprint length is more than just the frequency of the ceremonies. Each experiment tremendously impacted our way of thinking, team dynamics, and approach to various issues.
Most importantly, each experiment led to learnings that were applicable regardless of length. With one team, I started with biweekly sprints, moved to weekly, then daily, then back to biweekly. Although we eventually stuck to biweekly sprints, previous experiments forced us to change our approach and helped us uncover many insights about our work, and these insights now help us work better in a biweekly cadence.
We never regretted any experiment, even though we reverted most of them. So, don’t be afraid to experiment and break the rules if needed.
Observe your cycle time and predictability to assess whether you are in the right spot or need a change. I believe you should adapt our sprint length depending on the current circumstances, which tend to change.
Do you have any dream or nightmare stories of running sprint experiments?
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
