📜 See all articles: Sitemap
⬅️ Previous Article: Sprint Planning
➡️ Next Article: Continuous Playtesting
Milestones segment your development into digestible yet substantial chunks of work. They'll help you get from prototype to vertical slice. Later, they'll organize the process that takes you from vertical slice to shipped game.
While a milestone by definition refers to an event (”we hit the first milestone”), it’s also used in game development to denote a period of time (”our milestones are three months long”).
Milestones are typically measured in months or sprints. In my work, I like to create milestones that are three months long (every 12 weeks, every quarter, or every six two-week sprint: however you choose to look at it).
Three months is both digestible and substantial. Let’s take a look at these two words:
Digestible
Building a full game is an overwhelming undertaking. Working on your game for three months is a bit more manageable—especially when you start to think about it as six sprints. Still hard? Definitely. But you can plan it, and you can understand it.
Substantial
Your game will take a big leap forward after three months! It won’t always take much of a leap forward after one sprint. If you’re constantly judging progress by the sprint, you’ll get demoralized. But if the team waits until the end of the milestone to look back, they’ll undoubtedly be impressed by their progress. Morale will remain high.
To reiterate a point I made on morale in Estimating: morale seep is particularly toxic for startups. If you’re a solo dev, your morale is the key to working hard and staying focused on your game. If you’re leading a team, their morale is crucial to their continued involvement and investment in your game. You’re probably not paying people much at this stage (if at all), and so a large part of their diet is momentum and morale.
Beyond the need to create digestible, substantial milestones, there are two more reasons my milestones don’t exceed three months:
People generally need their wind-up engines cranked about once a quarter. Otherwise they slide into the doldrums. It’s energizing to restart the clock (as long as you handle planning well—see below).
Any longer than three months and you limit your ability to make agile development decisions. As you build your game, you’ll undoubtedly deviate from your initial designs. Milestone planning is an opportunity to re-chart your course and set sail for a better destination.
Implementing Milestones
Here’s the basic structure you’ll use to implement milestones:
Spend a week planning your milestone. Figure out where you want the game to be in three months, scope work, and set up your first sprint.
Lead the team through six successive sprints. Reprioritize work as needed, but keep the milestone’s goal in focus.
Wrap it up and repeat.
Milestone Planning
It’s essential that you nail milestone planning in order to prioritize the most important work, energize the team, and hit the ground running. Milestone planning should feel a lot like pre-production. It’s the prep work that ensures production is a hit.
I give milestone planning a full week. While you as the designer and/or producer will be involved in each day’s activities, it’ll be a light week for the rest of the team.* For relevant team members (typically those involved in coding), this is a good week for bug work. For all other team members (say, for art and sound), I ask them to pick 1-2 in-game assets and improve them. Typically there’s something they’re not quite satisfied with, or something they’ve been wanting to improve. I can’t overstate how much life these little improvements—which I call “free play”—add to your game. I cover the concept in more depth in Sprint Planning.
*This can be an exhausting week for the meeting averse. Keep that in mind, and don’t overburden them with tasks that make them resent the meetings that they’re participating in.
Day 1: Postmortem & Planning
This day has two main goals:
Run a postmortem on the last milestone
Plan the next milestone's theme
Postmortem
A full-team postmortem is essential to continuous improvement. An hour is a good length for this round-table discussion. Some good questions to ask yourself and the team:
Did we accomplish the goal of the milestone? If not:
Did we set the wrong goal? If so, what went wrong during planning?
Did we deviate from the goal? If so, why? Was it wise?
Did we assign too much work to this milestone?
Did things start to fall apart in sprints 4-6? If so, why? What could we have done better?
What work are you most proud of from this milestone?*
What feels most important to tackle now?
I recommend providing these questions a day or two in advance so that people can think through them. Typically people are crickets when you put them on the spot. It’s imperative that they have voices.
*Don't underestimate the power of positivity in a postmortem. Celebrate your team’s successes just as you workshop their failures.
Planning
While milestone brainstorming is a full-team activity, you (and your co-founders/other designers, if you have them) are uniquely equipped to chart the game’s future. It’s your vision that brought the game to life, after all. After the post-mortem concludes, and the team has a chance to share their feedback with you, it’s time for you to do some planning.
Your goal is to come up with the next milestone’s theme. A lot of the time, it’s kind of obvious. If your gameplay loop is unfinished, you have to complete it. If it’s done, but your moment isn’t hitting, you need to find ways to bring magic to your formula.
Sometimes your theme corrects balancing issues. If encounters are lifeless and predictable, you’ll need to spend serious time and brainpower making them satisfying. That alone can be a theme. It’s best if your correction aligns with one of your creative pillars, adding a bit of poetry to your theme and making it open-ended enough that it can encapsulate all sorts of work.
It’s not always neat, though. In some cases, you’ll have 2-3 discipline-specific goals you’ll need to accomplish. For example, art may need to focus on the beautiful corner, UI may need to focus on the menu system, and engineering may need to focus on movement mechanics. Sometimes you just need to do disparate work, especially when you’re getting towards the end of your vertical slice. It’s okay to have multiple goals. Since it’s usually a sign that you’re getting later into the development process, you might be able to use a word like “polish” to encapsulate the work that has to be done.
Whatever you choose, come out of your planning session with a theme that the team can rally behind.
Day 2: Brainstorming
This is your big team brainstorming day. Share the theme with the team in advance, then bring them into a brainstorming meeting. I like to allot two hours to this meeting. It’s probably longer than you need, but people really disengage when you go over time.
I recommend using a Miro board to capture the team’s ideas. It’s more or less a virtual whiteboard. Create a sticky for each discipline to cluster ideas around. Since you know some of the essential work that needs to happen, it’s helpful to pre-populate the Miro board with some must-dos. Leave room for individual brainstorming in the meeting—5-10 minutes of solo work can generate some great ideas.
You want to leave this meeting with a goal sheet for the milestone. It's nice when it's topped with a statement. If I ended day 1 with a theme of Living World (one of my creative pillars), I might end day 2 with just this statement: Create a world that feels alive through improved enemy engagement, significantly more environmental ornamentation, attenuated sounds, and environmental shading.
Below that statement, I’d jot down any ideas that I want to capture from the meeting. Above, I was able to distill the (very much fake) team feedback into four categories. Below, I might make a long laundry list of things we need to accomplish to take the game to the next level. You can think of this as the milestone’s acceptance criteria.
Don’t be afraid of scope creep here. You’ll be able to pare it down later this week. This is an ideas day.
Day 3: Development
Meet with anyone involved in development. Go through the list of dreams you compiled the last two days and start sizing them. This takes a good amount of work, so I’d recommend starting with the really crucial stuff and working your way down. There will be hard cuts in here. Make sure you’re aligning your development choices with your creative pillars.
Your goal here is to select a list of work that doesn’t exceed your team’s capacity over the next six sprints. You’ll need to know how many points each team member can commit to per sprint. Take a look at Sprint Planning for more details.
It’s a little impossible to size everything to perfection in this meeting—especially without research. You can leave some 21s on the table (see: Estimating). The key here is to avoid planning too much work. Trust me: you can always fill empty space.
In that vein, consider adding a buffer for bugs and unexpected features. If you think each team member can handle 80 points of work per milestone, allocating only 60-65 points leaves room to tackle the unknowns that inevitably crop up during development.
Day 4: Sound and Art
Next, do the same thing, but this time with your sound and art people. It’s essential you meet with these disciplines after development, as a lot of sound and art requirements branch from development decisions.
Day 5: Allocate Sprint Work
This is your planning day for the first sprint of your milestone. Be sure to share details about the upcoming milestone with your team. Get them energized about what’s to come.
When to Avoid Milestones
A rigid system of quarterly milestones doesn’t fit every project. Often, vertical slices for indie games don’t require multiple three-month periods to come together. You may find yourself working outside of a milestone system at the end of the project or planning a shorter, 6-10 week milestone.
If you think the whole project will wrap up in 3-4 months, I still advise treating that like a milestone—and I advise going through all this planning. Getting it out of the way first makes everything else feel better. Is it a headache? You bet. But it’s way more jarring to enter a planning vortex every two weeks. It's essential to keep the team in a good production rhythm.
The last few articles have covered organizational tools that help you keep your project moving. The next covers a design tool, and one of the most important aspects of game development: Continuous Playtesting.
📜 See all articles: Sitemap
Comments