Sprint Lengths and Long Releases

If you're not careful, the length of your sprints may become a one size fits all solution wherein you try to shoehorn every development effort into a 2 week iteration or some other length. I try to caution people from reaching this point for a number of reasons.

Certainly, having a shorter sprint size has it's advantages because the shorter time frame allows for more accurate planning, faster feedback and a bit faster pivoting for the team. There's another side to this as well though, before every sprint you have to have a sprint planning meeting. Ideally your developers will estimate (or reestimate) their work items right before the sprint. Before you plan the next sprint, you need to review the sprint and perform a retrospective. All of these things are good and should be done between each and every sprint, but they also mean time that the development team is spending away from more important things, like development.

And therein lies the conundrum. Traditionally you would try to reach some kind of happy medium for sprint length and that sprint would become the heartbeat of iterations for your software. Every 2 weeks, 3 weeks or 1 week you would finish the sprint and there would be a new potentially shippable iteration of the product. This is good, many teams will start doing this and will likely continue because it works great, but don't let it become a rigid law for your organization.

But here's a thought: no Scrum rules should overcome a thoughtful decision made by an intelligent person (which I'm assuming you are). Which is to say, we should protect the team from being overburdened by the Scrum Framework.

What if we were working on a long-term unannounced project? Perhaps it's a AAA game title or an entirely new product with a deep feature set. In either case, customer feedback isn't that useful since our customers don't even know the product exists. Moreover, for at least the first few sprints, the development team's focus will be more towards achieving a minimum viable product.

This doesn't mean that we throw Scrum out the window, in fact just the opposite. Sprints, retrospectives, planning and the product backlog become even more important. Since this specific article is about sprint length we'll start there.

If this is a new team working together for the first time, short sprints are probably best so that we can loop back in often for retrospectives, maybe a one week sprint or so (shorter or longer, it's up to you). Tuning a team to work together will make your life much easier on the long road to the release.

Once the team is comfortable working as a unit, those retrospectives (while useful) can be seen as overhead if they're done too often and since the product backlog primarily consists of Minimal Viable Product work at this stage, priorities are unlikely to shift too often. As we begin to settle in for a long release you can lengthen your sprints (every two weeks or every month). You'll still track your daily progress via the burndown chart and your daily standups, but will loop back in to finish the sprint less often.

Once you begin closing in on a release, feedback becomes important again, functional testing will provide new insights, tweaks on the original design are made, beta testing will finally allow for customer feedback, etc, etc...

Because of all the new feedback as we get closer to a final release, it can become important to shorten up the sprint length again to allow the team more room to change direction and priorities between sprints.

Using variable sprint lengths are probably not the norm and is usually reserved for longer development cycles with a minimum amount of customer feedback, but ultimately the sprint length is a tool for the Scrum Master to experiment with and use to the development team's advantage.

What are some of the things you've noticed about how sprint length affects your team?