How Long Should Your Sprints Be?

Everyone runs two week sprints. It's the norm, the standard, the thing we're taught. 

I also think it's incorrect A LOT in game dev.

Sometimes, you shouldn't be running sprints at all.

Sometimes, you should be running shorter - occasionally much shorter - sprints.

How do you know what the right sprint length is?

First, let me list out the three primary dials you should use to set sprint length:

1. How long does it take to get a valuable piece of work done?
2. How often does the environment shift in a way that impacts priorities?
3. What makes sense for humans?

What else is worth considering? Let's look at five more things to keep in mind:

1. How much time do you have left in the project? I've run "sprints" as short as a couple hours during 2-day "Fedex" days. If you only have a month to get something done, having 2-week sprints won't allow you to pivot and adapt too much. For very short timelines, shorten your sprints.
2. What's your release cadence for the game or product? It can make sense to have sprints fit nicely into release cadences. This doesn't mean they have to match. If you do a major release every four weeks, 1-week or 2-week sprints will fit nicely for a team, but 3-week sprints will be a bit awkward. If you release every week, you might match with 1-week sprints, but could also use 2-week sprints and just hit every other patch if that makes more sense based on the other dials. But it's helpful to be able to line up your cadence with releases.
3. How often are you playtesting? Same idea as releases. You create sprints that match your main playtest cadence. It may not be playtests, but instead how frequently you can ingest learning from playtests. You use the playtest + time needed to adjust priorities from the playtest to inform your cadence. This also keeps people looking at the playtests and grounded in the reality of the game you are making/improving.
4. Where are you in the project life cycle? Early on, you may be learning a lot and need to react to that rapidly. As you have a clearer understanding and your pipelines stabilize, you end up being able to run longer sprints with more focused days of work in a row without much risk. Once you get towards the end of the project, you may either tighten sprints back in or abandon them altogether in favor of a flow-based approach. The main thing I'm calling out here: don't think you need to establish one cadence and keep it throughout development. You don't want to change it constantly or it loses a lot of value, but that doesn't mean you shouldn't re-evaluate as your work system adapts to new phases of dev.
5. Are your devs full-time, part-time, or side projecting? If you're a hobbyist game dev working in your spare time, using sprints at all is probably not be the move. It's a lot more important to focus on doing the next most important thing regardless of how long it takes. If you're a bootstrapped indie team working with part-time, variable-time team members, running tight sprints will probably not go well. How much your team is able to engage will impact some of the factors above. By the way, this applies even in large stable companies when you see people split across multiple projects. Lack of focus probably means everything will go slower. Worth keeping in mind.

I skipped over the top three because I talk about them in a recent podcast episode (link below), here's a quick explanation of the primary three dials.

1. Time To Get Valuable Work Done

"Valuable" here is defined as something that either teaches us something important, or something that positively changes the player experience.

In all your work, you should be either learning or making a more engaging experience. Knowing how long this takes approximately gives a rough guideline about how long sprints should be, because if you can't get valuable work done in a time period, adjusting priorities and work won't make much sense.

My warning: sometimes bad tooling means the time to get work done is TOO LONG for your environment. Don't let slow systems artifically lengthen your sprints. If it takes weeks and weeks to get a release built, that's a technical problem. It should not be used to justify 6 week sprints.

2. Frequency Of Prioritization Changes From Your Environment

Are things changing constantly? Is the learning happening so fast, or the leaders changing their minds (for good or bad reasons) a lot? If so, you want a tighter sprint, sometimes all the way down to daily sprints. If significant changes occur every few days, and you're running two week sprints, you end up either canceling a ton of sprints or doing a lot of less valuable work. When things are much more stable, and what's most important tends not to change, larger sprints function well.

3. Human Working Norms

If you ended up realizing that you should have 7-working-day sprints (so a little less than a week and a half), I've got news for you: no you shouldn't. While the "ideal" length of a sprint theoretically might be 4 or 7 or 12 days, you should probably set your sprint length to something humans are used to working with, that match our calendars and thinking. Humans think in hours, days, weeks, etc. and having large sequences of 4-day sprints makes it hard for people to settle into patterns.

Keep your sprints in patterns humans easily relate to. It'll make a lot easier.

Something Else To Ponder

My rule of thumb is shorter sprints earlier in dev while a lot of learning, prototyping, and ideation is happening. BUT, I was in a great conversation with Leif Johansen and he brought up a case where you would use longer sprints, or no sprints but a fixed plan at the start: when you and the team have a lot of familiarity with the foundations of what you'll be building, and nothing is likely to change.

When you have high confidence of what you need established up front, that certainty of what's needed AND the clear knowledge of how to get there makes either a plan-based approach or significantly longer sprints completely viable.

My HUGE WARNING about this: I know a lot of people that THINK they know what it will take to lay foundation, or set up the tools, or whatever else they believe is the first step. For someone like Leif, who's spent years and years making the type of game he's working on, this can work - though I'll still call it a risk. For someone who is working in a space they aren't familiar with, or with devs who aren't familiar with the toolchain or the space, I recommend NOT doing a plan-based approach to lay your foundations. By going plan-based you are essentially saying, "I don't have that much to learn about these foundations." Your ego will tell you that's true way before it is, and you'll pay the consequences trying to get it all out in one shot.

My Default Sprint Length

My recommendation? All other things being equal, I recommend starting with one week sprints. With more info, I adjust that, but I warn you, I tend to want it to be shorter rather than longer. It's only in very specific circumstances that I'll go to 2-week or longer sprints or a plan-based system. 

The answer to "How long should my sprints be?" is, as it almost always is, "it depends." But I hope this has helped you understand what it depends on.

If you're interested in checking out the podcast for more thoughts and a better explanation of plan-based, iteration-based, and flow-based systems, you can find it here: https://youtu.be/HIjVRXJbBy4

Interested in leveling up as a leader?

If you’re a leader in game dev who feels stuck, able to spot problems but struggling to make a real difference, there is a path forward that levels up your leadership and accelerates your team, game, and career. Sign up here to learn more: https://forms.gle/nqRTUvgFrtdYuCbr6 

Here's to building better games!

Ben C.