In my previous blog post, I talked about sprints in the ethereal discussing their similarities to deadlines and reminding us to be inquisitive of the world around us. However, I offered no practical advice. Today, I’d like to remedy that. Below, I tackle many common questions about sprints. Let’s get started.
So What’s the Right Sprint Length?
As short as we can get away with but probably no shorter than a week. Every sprint is an opportunity to learn, and we want to maximize this learning. At the review, we learn how valuable–or not–our increment was from our customers. At the retro, we learn how well–or not–we worked together from our team. As such, the shorter this cycle is, the more often we can learn. Before we begin using one-week sprints, however, we need to ask ourselves an important question:
How often can we deploy to our target environment?
If the answer is at least once a week, great! Maybe we should try one-week sprints. If it’s once every other week, maybe two-week sprints are better. However, if this number is greater than a month, it gets awkward. As the manifesto tells us, “Working software is the primary measure of progress.” If we’re not delivering working software frequently—ideally, continuously—then we should pay time and attention to shortening that cycle. Why?
If we can only deploy a few times a year, can we rightfully claim to be agile?
My answer is no. We can’t. I’ll revisit this idea in a future blog post since I realize more elaboration is necessary so stay tuned.
Finally, I realize that some might cringe at the idea of a weekly cadence. They might say, “We already spend too much time in ceremonies! One week sprints will only mean more!” I said much the same, but changed my mind once we experimented with them. If we spend 1.5 hours in sprint planning for a two-week sprint, we should expect to spend no more than 45 minutes at planning for a one-week sprint. The same goes for the remaining ceremonies so we’ll likely spend less, not more, time in ceremonies. Sure. They occur more frequently, but this is good. It increases our capacity to learn.
When Should Our Sprints Begin And End?
Some prefer Monday to Friday sprints. Others prefer to start sprints mid-week, and others still prefer an “admin day” where we tackle planning, review, and retro in a single day. Pros and cons exist for each.
| Cadence | Pros | Cons |
|---|---|---|
| Monday to Friday |
|
|
| Thursday to Wednesday |
|
|
| Admin Day |
|
|
How Often Should We Change Sprint Length?
As infrequently as possible. Establishing a tempo helps the team work effectively so avoid changing sprint length. That’s not to say we shouldn’t experiment. Instead, exercise a level of prudence when trying out new sprint lengths. One notable exception is Mike Cohn’s idea of 6 x 2 + 1. Mike suggests breaking each quarter into six two-week sprints. The final 13th week of the quarter belongs to the team. Have a read over Mike’s blog post for the details. I haven’t used that technique myself, but it shows a lot of promise.
That’s all for today. If you have questions or thoughts, I hope to see them in the comments below.
Do you want to get notified when new posts are published? Leave your email below.
Good information and succinct Tanner!
We’ve used Wed-Tue for some of the same reasons you indicated above (Thur-Wed) plus most of the holidays in the US seem to fall on Monday or Friday so we bypass those situations too. Only minus is the Monday holiday where sprint review is Tuesday and we just make sure to bring that up during our planning and identify ways to mitigate that
Thanks, Craig. Although I say Thurs to Wed above, any mid-week day will do, and you’re right about holidays. Mid-week sprint starts with holidays usually mean cancelling a single stand up instead of rearranging a bunch of ceremonies.
I really like the admin day approach. My current team decided not to try it as they had previously been experiencing meeting burn out but I’ll be trying for that with my next team (bouncy consultant here). I’ve yet to try 1 week iterations but I’m very intrigued by this idea. At my last training opportunity Nigel from Scrum Inc was a big proponent for 1 week sprints and his data shows an increased velocity using this time frame.
Let me know how your admin days turn out for you. And one week sprints, assuming you give them a go some time down the road.
Great post Tanner, thanks for sharing. I have 2 teams at the moment, one on 1 week “sprints”, (I’ll explain the speech marks), and one on 2 week sprints. The 1 week sprints operate on a kanban approach. We try to do regular retros and reviews but the team is small and the PO is closely aligned to what we deliver so it always feels overly heavy to perform those ceremonies for each weekly increment. We’ve used the Admin day for the 2 week sprint team with some success, (I’ve used this approach for a number if years in fact), but have found that it’s a very heavy day on the team, so have split the planning to happen in the morning of Sprint day 1, which has worked well for the last 2 sprints. The main message is that most approaches work, dependent on what works for the team, so long as you respect the basics of the process & can be ipen to change when required to continue to deliver quality.
Thanks for stopping by, Paul. I realize as well that admin days can be brutal for some teams while others like it, and it’s worth reminding us that it’s not about what we prefer. It’s about what works for our team. Usually my ask of a team is the same as my mom when I was a child:
Don’t tell me you don’t like something until you’ve tried it.
Speaking of which, did those 1 week “sprint” teams try a review and retro every week before tossing out the idea? And for all intents and purposes, isn’t that really just a two week sprint anyway? I ask because a kanban approach just tosses out silly things like planning and just focuses on completing the most important work as previous work is completed. So is that team really using Scrum or something other?
I’ve used M-F, W-T, T-W for sprints and like W-T the best. One anti-pattern that muddles the water that I’ve seen especially for M-F sprints, is teams leaving the sprint open over the weekend, people working over it trying to finish stuff and get higher output due to outside pressure and perceptions and not having a consistent time box to inspect and adapt with.
If that overtime happened only with M-F sprints, I’d likely want to keep them where they’re at so I can give the anti-pattern some attention and exposure. After all, changing the cadence doesn’t solve the problem. It simply obscures it.
But that’s tangential to your comment. I’m glad to see mid-week starts and ends have worked well for you.