Add a Longer Cycle Around Scrum Sprints

There I sat with the CEO and the VP of marketing. We were discussing what my teams could deliver in the coming quarter. The teams were all using two-week sprints and we knew the velocity of each.

The VP of marketing asked me how many sprints we’d complete in the coming quarter. You see, with two-week sprints, sometimes you can finish six sprints in a quarter, but other times you can finish seven. It all depends on whether the quarter starts with a new sprint or starts halfway through a sprint.

So I start doing the math in my head to figure this out. And I’m thinking: September 10, September 24, uhh, how many days in September? OK, 30, so that’s October 8, October 22 …

And right then I decided that having to do that was an unnecessary hassle. I hated that some quarters had six sprints and some had seven. And I decided that from then on, each 13-week quarter would have six two-week sprints.

But, six times two equals 12, and there were 13 weeks in the quarter. What should I do with the 13th week?

I decided I would give it to the team.

Every quarter, the team would have one week to do entirely what they wanted. It needed to be project- or company-related, but they would determine what to do.

Some teams used it to do refactorings they hadn’t been able to convince the product owner to do. Other teams used the time to learn new skills. Still others experimented with ideas of their own that later became some of the best features in their products.

There were three unintended but important additional benefits to this.

First, it gave product owners a week away from the pressures of staying current in a sprint. Product owners used this time to think more strategically about their products, get the product backlog in good shape for the next quarter, visit customers or do other research.

Second, it established a longer cycle than just sprints one after another. We found this cycle helped us take a longer term view of the product. Instead of starting each sprint with a focus on what was most urgent for the next two weeks, we began to think about what was most important for the full quarter.

And with that longer term view, the teams were able to deliver more value to their product owners.

Since then, I’ve worked with companies that have used many variations on this “6 x 2 + 1” approach. For example, three four-week sprints plus a one-week sprint left up to the team works well.

I’ve even seen five two-week sprints followed by a three-week sprint of work selected by the team. This was a team with a lot of refactoring that needed to be done, which the team did during the final sprint of each quarter.

A third, unintended benefit was that this 13th week was not considered in making quarterly plans because no one knew in advance how the team would use it. This allowed teams and product owners a built-in buffer if they ever needed to use that week to meet commitments. And if the team gave up “their week” in week 13, so what, their product owner would give them week 15 or 18 instead.

I believe you will find a lot of benefits to establishing a cycle that wraps around a series of sprints.

And those benefits will help you succeed with agile,