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? tweet
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? tweet
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.
|Monday to Friday||
|Thursday to Wednesday||
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.