📜 See all articles: Sitemap
⬅️ Previous Article: Backlog Management
➡️ Next Article: Milestones
It's time to answer all the burning little questions about sprint planning. By the end of this article, you'll have all the tools you need to start planning your own sprints—or your money back.
While I try to hammer this home a lot, let’s do it once more: this isn’t the way you have to set up your studio. This is just one framework you can use to manage the game development process.
Overview and Structure
I start and end sprints on Wednesday mornings. Nothing too controversial here—Wednesday is probably the most common sprint start day in the industry.
There are several reasons to avoid other days:
Mondays: nice for how they align with the work week, but you end up missing staff due to long weekends and holidays. Sprint starts are some of the most essential days to have all hands on deck.
Thursdays: late in the week, so the weekend creates a big time gap right as your team’s building momentum.
Fridays: the worst day to start a new project.
Tuesdays are an acceptable alternative to Wednesdays, but I find they make Mondays into awkward endcaps. It’s hard to get back into flow for just one day.
I schedule the last sprint’s review and the next sprint’s planning meeting simultaneously (again, not controversial—standard practice). Why?
No gap: a gap between these meetings is a space where nothing’s going on—the last sprint has ended, but the next sprint hasn’t begun.
Morning meetings only: having the review at the end of the day on Tuesday cuts off part of the afternoon for finishing up last-minute features. In general, I discourage end-of-day meetings. People start to check out.
Your Wednesday morning meeting is beefy and has four parts:
Review
Retrospective
Playtest
Planning
Review
During the review, you’ll want to walk through each work item from the previous sprint and talk to its assignee. If it got done, that’s all that needs to be said. If not, you’ll ask why. Was the item blocked? Were there complications?*
If necessary, you'll then resize the feature and decide whether to roll it over to the next sprint. If the feature hasn’t been started, or it bears way more complexity than expected, you may decide to deprecate it entirely. It’s just a question of where your priorities lie. Stack the unfinished feature up against what’s planned for the next sprint and decide what matters most.
Once you’ve gone through everything, it’s on to the retrospective.
*Complications are often due to sizing issues--something to keep in mind when you're triaging.
Retrospective
After you review the work items from the last sprint, take 10-15 minutes to discuss how it went. Was work well-sized? Did blockers get out of the way? Were there too many meetings? Not enough? This is an excellent opportunity to zoom out and review your production flow.
Be open-minded throughout this process, and don’t feel shackled to a system that doesn’t work for your team. Make changes, experiment, and find the system that works best for you and your game.
Playtest
In Continuous Playtesting, I talk about having a theme for each playtest. On sprint day, I center the team’s focus around the previous sprint. I put emphasis on exploring the new features, art, and sound that have been added to the game. This is an opportunity for your team to showcase their progress, but it’s also an opportunity for healthy critique. Oftentimes new implementations require balancing and tweaking. It’s best to capture that in the direct aftermath of their development. This may add work to the backlog, and it’s up to you to decide if that work is necessary or aspirational.
While I typically advocate for playtests to last a full hour, I recommend keeping this one closer to 30 minutes (if your game supports that). It's already a lengthy meeting.
Planning
This meeting segment is pretty straightforward. Prior to the meeting, you (or whoever’s handling production) should have planned out the next sprint according to your team’s capacity and their availability. Sprint planning is simply an opportunity to share that with the group. There may be some swaps and adjustments on the fly, but for the most part, sprint planning happens before the meeting.
But how do you figure how much work to assign each person? This is where we’re going to get into the land of personal preference. The framework below works for me. I hope it works for you! If it doesn’t, change it to something that makes more sense to you.
The important point to note here is this: I judge the capacity of any individual, barring non-sprint work and time off, to be 21 points per sprint.
I roughly correlate sizes to time periods according to the following system:
21 points: a full sprint—too large and must be broken down
13 points: a little over a week
8 points: 3-5 days
5 points: 2 days
3 points: 1 day
2 points: half a day
1 point: an hour
As you can see, these numbers don’t line up perfectly. That’s not a big problem; estimates cannot be a 1:1 match to time blocks by virtue of being estimates. See Estimating for more details on my philosophy.
I get away from biblical scrum with this next part, but I think it makes for a healthier game development environment. Though each teammate has a 21 point capacity, I cap backlog work at 16 points.
Here’s the way each teammate’s work is allocated:
16 points of backlog work (max) -- this includes bug work and code refactoring
3 points of tuning
2 points of free play
Tuning
If you’re running continuous internal playtesting, you’re bound to discover a ton of bugs and implementation issues. As the list of necessary tweaks grows, it starts to feel a lot like debt. Your bag gets heavy with little tasks that you’ll someday need to tackle.
Left unchecked, these little tasks seem to multiply, and they become overwhelming. They may even merit their own cleanup sprint.
You want to avoid cleanup sprints like the plague. Are they sometimes necessary, especially at the end of a project? Absolutely. But in the middle of development, you want to keep that backlog clean and fresh. So practice tuning.
I use the word “tuning” to refer to the little work uncovered by playtesting. It’s often nominal, never more than a point (or else it merits the creation of a new backlog item). Tuning creates a feeling of momentum when the team solves your game's most visible small issues.
There’s nothing like going through a playtest and hitting the same small bug you encountered last week, or hearing that musical cue proc at the wrong point yet again. It’s demoralizing! It feels like things are stalled out.
You want your team members to feel like the issues they bring up during playtest are getting addressed. When they're fixed, people have something to celebrate. When they're not, it feels like a growing issues list is bubbling under the surface.
The best part is that these are often the things people are most motivated to tackle. People have a tendency to want to fix simple, visible issues and achieve little victories. When we prevent them from working on tuning tasks, we do it for good reason—to keep them focused on the important stuff. But I think this creates cobwebs, and I want people to have the freedom to clean out the cobwebs before they really get entrenched. If cobwebs grow, playtests themselves start to feel overwhelming. People are reminded of all the work they’ll eventually need to do. Better to avoid this.
Three points of tuning is just enough to dust off a few cobwebs each sprint without taking away from the mission.
Free Play
Everyone grows unhappy with some aspect of their work over the course of development. Everyone can improve on something they’ve rushed to finish. To see what someone’s truly capable of, consider adding free play into your sprints.
Free play gives team members the freedom and agency to improve their work. They’ll do things like retexture assets, attenuate sounds, balance an upgrade system, or add visual flare to an explosion. When you go around the room during a sprint review and ask people to share their free play task (which I do), the team will often say “that’s sick.” And that’s the point.
Free play makes your game feel more like a collaborative effort. It adds color to the game.
I wouldn’t designate more than 2 points for free play. Between tuning and free play, you’ve already carved out close to 25% of the sprint for non-backlog work. That’s certainly not time lost, but it’s a lot of time reallocated.
In game production, I care about on quality work, high morale, and the avoidance of tech debt. I find that tuning and free play help me accomplish these goals. Give them a shot; if they don’t work for you, revert to a classic backlog-only sprint allocation.
Mid-Sprint
If I’m not running standup meetings, I ask people to post the following in a stand-up Discord channel:
What they did yesterday
What they’re doing today
What’s blocking them
Typically I’m looking for them to do this as soon as is convenient for them. If it’s a full-time team, I’m looking for this by 10am, which is when you can [hopefully] assume people are sufficiently awake and moving.
My philosophy is to playtest whenever possible. If that’s not daily, I try to do it every other day. For a sprint starting on Wednesday, my preferred schedule would be:
Week 1: Wednesday & Friday
Week 2: Tuesday & Thursday
At the exact middle of the sprint (Wednesday), I emphasize no meetings. This is pretty common practice, but Fleur Marty first turned me on to it.* It’s a great “get shit done” day.
*I took a lot of inspiration from Fleur when writing this article and Milestones. She’s brilliant!
Sprint End
This is when you cobble together the next sprint. In my format, it happens on the last Tuesday. Planning usually involves conversation with your teammates—no one likes being blindsided by new work, and they’re generally needed to validate sizings and requirements. Just make sure you don’t take too much of their time for planning. They’re at the end of a sprint, and their heads will be down.
Now that you know how to structure sprints, it's time to zoom out to their overarching organizational structure: Milestones.
📜 See all articles: Sitemap
Comments