Why Longer Sprints Probably Won’t Help

As a coach, I’m frequently told, “Our sprint length is too short. We want to change it from X to Y weeks.”

The time box—the sprint in Scrum, the iteration in XP and other iterative methods—is one of the most powerful tools in agile software development for revealing problems in a team or organization. Notice I said reveal, not fix. I’ve seen a few cases where the sprint length really was too short. More often, though, the feeling that the sprint is too short is a sign of deeper problems. Lengthening the sprint might push these problems back under the surface, but it’s unlikely to actually solve them.

Before you increase your sprint length, ask “Why?” a few times to see if you have any of the following underlying issues, and try to deal with those first. Maybe your sprint really is too short. But don’t start there, lest you miss an opportunity to improve.

Underlying Problem #1—You’re trying to do “mini-waterfalls”

It’s very difficult to fit a mini-waterfall cycle into 1 or 2 weeks. If you regularly find that testing starts late in the sprint and gets less time than it deserves, experiment with something like ATDD to move testing earlier in the work and try working on fewer stories at a time.

Underlying Problem #2—You struggle to split stories

To maximize predictability without too much overhead, I recommend 6-10 stories in a sprint. Sometimes teams want to increase their sprint length because they struggle to get even one story small enough to fit into 2 weeks. Instead of increasing the sprint length, work on your story splitting skills for a while. Splitting stories is a skill that takes time and practice to develop.

Underlying Problem #3—Meetings take too long

Perhaps your Scrum meetings, especially Sprint Planning, are long and painful. It’s natural to want to do them less often. But consider this: Do you expect to do 50% more work in 3 weeks than you did in 2 weeks? Probably. Then you’ll have 50% more to talk about at Sprint Planning. The most effective hour of a meeting is usually the first hour. After that people, get tired and distracted and accomplish less. So, by increasing the content of your planning meeting by 50%, you’ll probably increase the total meeting time by more than 50%. True, it will happen less often. But it will be even more painful than today.

Instead, work on getting better at your meetings. One team I coached decreased their bi-weekly Sprint Planning meeting from 10 hours to 20 minutes by

  1. doing regular backlog grooming every day or two for very short periods with just the necessary team members,
  2. planning using story point velocity rather than task estimates,
  3. creating tasks just-in-time during the sprint, and
  4. doing Sprint Planning in multiple passes, a high-level initial discussion and commitment based on velocity and then more detailed discussion of each story as needed.

Could one or more of these techniques help you?

Underlying Problem #4—Deployment (or merging or integration or whatever) is too hard

Perhaps you try to deploy completed stories into some kind of staging or formal test environment at the end of each sprint. Maybe you even need to engage outside release managers to do it. It’s difficult and time-consuming to do, so naturally you want to do it less often.

I wholeheartedly agree with the advice in Jez Humble and David Farley’s excellent book, Continuous Delivery: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” (p. 26) Instead of deferring the pain—and probably making it worse in the process—try to make it less painful so you can do it more often. If deploying every sprint is hard, figure out how to deploy nightly or on every commit. (Continuous Delivery is a great resource to start this journey.)

Underlying Problem #5—You can’t get anything done in 2 weeks

Sometimes teams tell me, “We simply can’t deliver anything valuable in 2 weeks, so we have to go to a longer sprint.” But changing your sprints from 2 to 4 weeks really hasn’t changed how much value you deliver in 2 weeks; it’s just given you half the visibility into progress. Instead of changing the sprint length, try these two things:

  1. Use a concept like the Minimum Marketable Feature to group user stories into larger units of value. You’ll still work on stories, but you’ll have better visibility into how those stories contribute to releasable value.
  2. Do some root cause analysis (e.g. the 5 whys or a similar tool) to find out why you deliver less value per week than you’d like. Maybe you have some technical debt you need to deal with. Maybe you have too much process overhead. Maybe a specialist is a bottleneck because skills are unevenly distributed on your team. Maybe you’re building on an out-of-date platform and could get more productivity with newer technology. There is a wide range of possible causes for low productivity. Whatever the cause, longer sprints are unlikely to be a fix.

Underlying Problem #6—It takes too long to get feedback

If the Product Owner takes a week to answer questions, it probably going to be very difficult to complete work in a 1 or 2 week sprint. But will a 3 week sprint be much better? Instead, find ways to shorten feedback cycles such as,

  1. take other responsibilities away from the PO so she can focus on her role,
  2. give the PO (or team) more authority to make decisions without having to ask hard-to-reach stakeholders, or
  3. work to increase knowledge on the team to reduce the number of questions that need to go to the PO or outside experts (ATDD can be a great tool to accelerate this learning, especially if you use it to build a ubiquitous language).

Underlying Problem #7—Dependency on outside specialists

Related to #6, sometimes teams can’t complete a story without help from a specialist outside the team—a DBA, tech writer, expert on a particular technology, etc.—and this outside person is part-time on many teams. Before lengthening the sprint to work around this issue, try to reduce the dependency by

  1. moving the specialist into the team,
  2. reducing the specialist’s load so he can be more available to the team, or
  3. growing the team’s own skills and/or authority in the speciality area.

Conclusion

If you’ve dealt with all the underlying problems you can find and your sprints still feel too short, then by all means, try a longer sprint length. Make your process for you. Just don’t start by lengthening your sprint and miss out on an opportunity to improve.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Excellent points! There’s a natural tendency for people accustomed to using waterfall to want to make sprints longer. It feels right to them. If they think back to the reasons for making the switch to an agile approach, they’ll realize that longer sprints only revert them closer to their old way of doing development.

    One suggestion I’d add is kanban. The advantage being that the concept of sprints largely goes away. Small units of work are consumed and completed independently. Releases can be scheduled at longer intervals perhaps making the team more comfortable. Food for thought.

    • @Vin – Thanks for the comment.

      Regarding Kanban…It certainly has some good applications. For this particular topic, though, I often come across team members proposing it as the extreme version of lengthening the sprint: “We can’t deliver anything in a sprint. Let’s switch to Kanban (it’s Scrum without sprints!) and we can take as long as we want.” Meanwhile, the underlying problems don’t go away.

  2. Hi Richard,

    This is an excellent post. I think there is no debate among “scrummers” that Sprints should be of reasonable size, otherwise, longer sprints will defy the whole point of Scrum.

    In any case, I would like to republish your article on PM Hut under the Scrum Category (by the way, an article that you might be interested in is this one). Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

    • @PM Hut – Thanks for the comment. I’d prefer that you not republish the whole post, but you’re welcome to use the excerpt that appears on my home page with a link to the full article.

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches people to collaborate more effectively with other people to solve complex, meaningful problems. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room. His book, Behavior-Driven Development with Cucumber, was published by Addison-Wesley in 2019 (for more information, visit bddwithcucumber.com).

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author