Six Times Two Plus One Equals a Good Project Cadence

In last month's newsletter I wrote about the idea that everything happens within a sprint. There is no "outside a sprint" during which team members might do things like design, bug fixing, or anything else. In this newsletter I want to share one possible exception to that. 

Something I've been doing for years is called 6x2+1. This stands for six two-week sprints followed by a one-week sprint. The idea for this came about many years ago when I was a VP of Software Development and in a meeting with the company's CEO and VP of Marketing.

We were discussing the coming quarter and what functionality my teams could deliver. The VP of Marketing asked me if we would have six or seven sprints in the coming quarter. He knew with two-week sprints we always finished six or seven sprints depending on when the quarter started.

To answer his question I started counting the sprints by thinking about the ending Friday of each: October 8, October 22, November 5, November 19, I counted. Then I had to figure out if November had 30 or 31 days. As I named each month on my knuckles, I decided from that point on each quarter would have exactly six sprints.

But six two-week sprints left me an extra week in the quarter. What to do with it? I decided I'd let the teams have that week to do whatever they want. Teams had been clamoring for more time to work on refactoring or any technically oriented thing they wanted but couldn't quite convince their product owners of. This would allow them one week each quarter in which to do whatever they wanted.

Selling the idea to product owners wasn't hard. I told them the team would still be adding value to their products during those weeks, it was just the teams would decide what was most valuable. To really sell the idea to product owners, I let them know one week per quarter the teams wouldn't need them as much, freeing them up for the bigger picture thinking and research the product owners had said they needed.

This was brilliant. I told the teams I was doing this for them. I told the product owners I was doing it for them. I was really doing it at first to get myself out of having to do date math on the fly.

There was one further benefit: This also gave each project one week per quarter that wasn't typically part of the plan when considering release dates. Whenever a project got into trouble and couldn't meet a planned date, we could use the thirteenth week as part of any normal sprint. We'd then give the team the seventeenth week, or any other later week.

Teams didn't care if they got the thirteenth or seventeenth week. They did care that they got a week sometime about once a quarter or so and very much looked forward to "their week."

Tying this back to last month's newsletter: Some of the teams with which I've done this 6x2+1 approach will treat the thirteenth week as outside of any sprint. Most teams will continue running Scrum for that one week. They'll do very simple planning and review meetings. Most will even conduct daily scrums just to hear what each other is working on.

But, some teams will do without Scrum altogether during that week. I'm OK with that although I'll admit my preference for doing a one-week sprint with extremely lightweight (short) meetings. So, this is the one time I'd consider some work to be "outside" a sprint.