📜 See all articles: Sitemap
⬅️ Previous Article: Intro to Production
➡️ Next Article: Estimating
What are sprints? They're a workflow style that breaks projects into predictable chunks of time (typically two weeks) to make them less overwhelming. Let's talk about why sprints are useful and how to structure them.
You may have heard the term “sprint” before. A sprint comes from the scrum project management framework, which is an agile methodology focused on continuous development and lightweight pre-planning.
Okay, I admit: that was buzzy. But you’ll pretty much always find a litany of buzzwords when you research sprint, agile, scrum, and similar terms. It’s a lot of project management philosophy, and it can get overwhelming. So let’s get out of buzzword hell and just talk about what a sprint is.
A sprint is a multi-week period during which your team completes a set of tasks to push your game forward. It’s a way of chunking your development so that a) it’s not overwhelming, b) you can make adjustments on the fly.
While sprints can last anywhere from 1-4 weeks, I typically plan two week sprints. Two weeks is long enough that you’re not constantly in planning hell, and it’s short enough to allow for frequent course correction.
Sprints create consistency in your game development process. That’s valuable if you’re a solo dev, but it’s essential if you’re running a team. Teams work best when they have shared momentum, and you’ll find that everyone will produce more once they get into a rhythm (note: this takes a couple sprints to get rolling).
Let’s walk through a sprint from start to finish:
Planning
Before each sprint, compile a list of tasks that you think you can complete in two weeks’ time. If you’re on a team, you (or your producer) will compile this list for each team member. This requires a good understanding of what each team member can accomplish, which we'll cover in the next article (Estimating).
Launching
At the start of each sprint, gather the team for a kickoff meeting to review each person’s responsibilities. This typically lasts anywhere from 30-60 minutes, and it’s at a consistent point in the week. I find a lot of people start sprints on Wednesdays. You can start them anytime, but I’d recommend starting them in the morning between Monday-Wednesday. Starting projects at the end of the week is bad for momentum.
Sprinting
After your kickoff meeting, it’s time to get to work! Make sure you keep an open dialogue through Discord channels or a similar medium.
Each day, hold a brief standup meeting (or equivalent—see below). In this meeting, each team member should say:
Here’s what I did yesterday.
Here’s what I’m doing today.
Here’s what’s blocking me from getting my work done.
It should last no longer than 15 minutes! It can often be done in 5.
Since a lot of new studios get built on the margins of the workday, you probably won’t have the luxury of hosting a daily meetings. You can accomplish standups via a Discord channel. Just have everyone drop an update (formatted according to those three bullet points) into the chat each morning. Many people prefer to work this way, as it conveys info without disrupting workflow. Adapt to your team's preferences.
Ending
At the end of each sprint, always do these two things:
Playtest
Talk about what went well and what didn’t go well.
First: group playtesting once a sprint is the bare minimum. Playtest at every available opportunity. As founder of your studio, you should be playing your game daily. Ideally, everyone on your team should play the game daily. Ideally, you all should do it together, during the same block of time, and compare notes/discuss it. That’s not always realistic, but continuous playtests are vital to the health of your game, so make space for them wherever possible. I write about that here: Continuous Playtesting.
Second: if work doesn’t get done, it’s crucial that you figure out what could’ve been done differently. Sometimes the issue is communication (was a task too vague?), sometimes the issue is estimating (was a task actually much bigger than expected?), sometimes the issue is capacity (have you adequately judged a team member’s capacity?), and sometimes the issue is blockers (did something need to get done first?). Whatever the case, find the issue, and make sure you allocate clear, well-estimated work to each team member according to their capacity.
That’s the basic structure of a sprint! I’ve left out a lot of jargon, and John Scrum and Jane Agile are probably rolling in their proverbial graves right now. But simplicity keeps us moving forward, and it’s more important for you to understand the basic structure of a sprint, not pass a quiz on scrum rituals and artifacts.
It should also be said that sprints are just one project management methodology. While I don’t think you’ll hate sprints, you might find a format that works for you better. Adopt it. The best system is the one that works for you.
In the next two articles, I'll introduce a couple tools to help you get sprints off the ground.
Estimating helps you figure out how long tasks will take.
Backlog Management helps you store and organize those tasks.
Since I reference the Estimating system in Backlog Management, I recommend you start there.
📜 See all articles: Sitemap
Comments