A Step-by-Step Guide to Planning and Executing a Game Development Sprint

You probably don’t need me to tell you this, but: making games isn’t easy. In fact, it can be the exact opposite! Game development is a complex process that requires a lot of planning, creativity, collaboration, time, and many, many other things–and in order to navigate all of them, being organized and methodical is a must. And one of the best methods to ensure your team stays organized, on track and productive, is by implementing sprints. 

Sprints, a staple of Agile methodologies, are short, focused periods during which teams aim to complete a set amount of work. A sprint mostly lasts between one to four weeks, depending on the tasks at hand and a variety of other factors (more on that later…). At Codecks, our team’s sprints last one week–and we call them runs, too. Having created a project management tool specifically for game development, with sprints in mind, and being game developers ourselves… We have quite a bit to share on how to properly plan a sprint. And we’re doing just that in this blog post, where we’ll go through all the ins and outs of planning a game development sprint, in a five-step guide with all you need to know. So, let’s get started!

Step 1: Define the Sprint Goals and then Create a Backlog

Just like when creating a GDD, or preparing the development of your game, for a sprint you need to start with setting clear and achievable goals. Ask yourself:

• What are the main deliverables?
• How does this sprint align with the overall project milestones?
• Are there specific features, bug fixes, or assets to prioritize?

Having well-defined goals provides direction and ensures everyone is aligned on the purpose of the sprint. Sprints only work if everyone’s pushing in the same direction–and setting up goals ensures just that. 

After you have the goals decided on, you can then focus on creating the sprint backlog, a prioritized list of tasks to be completed during one sprint, which will make sure everyone knows the main objectives and deliverables. Deciding on this list can be intimidating at first, but there are specific things you can do to make it easier, such as:

• Organize a brainstorming session: Make sure to involve everyone in the team, and brainstorm all potential ideas, tasks and features for the sprint. 
• Categorize tasks into groups: Organize tasks into categories such as “Game Mechanics” or “UI Design”, which will make the backlog much easier to navigate.
• Balance new ideas with existing tasks: Create a policy around creating new tasks, making sure the backlog keeps focusing on essential items. You could have an idea submission form, for example.
• Prioritize early and prioritize well: Use prioritization frameworks like the MosCoW method or ICE scoring to rank tasks right away. This will make sure essential tasks always take priority.
• Break down larger tasks into manageable pieces: Divide larger features into smaller, actionable items. For example, a goal could be “Make level 3 playable with 4 players over Steam”, and then the tasks could be “Set up spawn points in level 3” and “Integrate Steam friendlist”.  We’ve built Codecks with this in mind—that’s why we have Hero cards and then each one has its own subcards, acting as goals and tasks.         How to organize a sprint: start by defining the goals, then brainstorm, categorise and balance, and from that you have a list of tasks.

In general, we recommend keeping your sprint backlog concise—an overstuffed backlog can lead to decision fatigue. In our case, our backlog is the decks overview in Codecks, which keeps things visual and intuitive. Focus on maintaining a clean, actionable list to maximize efficiency during sprint planning.

For sprint backlog management, project management and, specifically, a project management tool come into play, as a service like Codecks can help you:

• Assign and track the specific time and effort to each task.
• Allocate tasks based on team members’ expertise and responsibilities.
• Serve as the main HQ for all sprint communications.
• Help keep all tasks organized and reported on throughout and after the sprint. 

All of this can then be seen and tracked on the tool, making sure you always have a bird’s eye view of the sprint and how it progresses. 

Step 2: Assemble and Communicate with the Team

Making a game involves a lot of different roles, including programmers, artists, producers, designers, QA testers and more. Different teams can work in different ways, and different roles have different responsibilities, so identify who will participate in the sprint and ensure they understand what their goal is. Communication is crucial, so make sure team members are all aligned before the sprint begins—don’t be afraid to encourage people to voice their concerns. Have pre-sprint meetings to set the tone for the collaboration, clarify dependencies and let people ask any questions. Transparency and communication are key in making a sprint work, even before said sprint actually starts, which is why you should have sprint planning meetings, to make sure everyone is part of the process in defining each sprint and is also aware of their role. Check-ins are also essential throughout the sprint itself—as we’ll discuss later on.

Use these meetings to finalize the list of tasks to include in the sprint, and ensure the workload is realistic—don’t be overoptimistic, and don’t overwork the team. Listen to each team member, and take into consideration things like: the team’s capacity, potential risks, blockers and dependencies between tasks.

Outside of any in-person or remote meetings, when it comes to team communication before and during sprints a tool like Codecks can be really helpful—it can serve as a place to store all your documentation, ask questions, and more. In our case, as a game development planning tool specifically, we built a whole Conversations feature specifically for this use!

Step 3: Set the Sprint Duration

As we said at the start, sprints last between one and four weeks, and it’s up to you and your team to decide how long your sprint should be. Choose a duration that suits not just your sprint backlog and the complexity of the tasks but also your team’s workflow—make the sprint fit within your way of working, not the other way around. In general: shorter sprints allow for quicker feedback loops, while longer sprints can accommodate more substantial deliverables. Shorter or longer iteration loops then depend on your team, of course. For example: teams in pre-production might favor shorter iteration loops, as they’re still figuring out the game and how the process will work. Once the game goes into production, however, you start working on a fixed content plan and pipeline, and for these teams longer loops might be better, as then weekly reviews might be too time-consuming. And then there are the stakeholders, too: some might prefer more frequent check-ins, while other teams might be more self-organized and need check-ins less.

On top of all this, consider also your team’s experience—if the team is new to sprints, maybe start with shorter ones, and incrementally make them longer as team members grow more comfortable. Once the team experience increases, keep sprint duration regular, in order to build a rhythm.

On one final note: always consider trying to align your sprints with your key project milestones, such as delivering a playable build or playtesting a feature, ensuring that the tasks that get completed (and scheduled on each sprint) are done so to ensure the milestones are achieved. For example: if you’re doing a monthly update on your game, then you need two sprints: one for testing, and one for stabilizing and getting everything ready for shipping. This isn’t a fixed rule, though—having this alignment between your sprints and your goals can be useful, but don’t limit yourself by it.

Step 4: Execute and Monitor Progress

Once the sprint begins, track progress daily. Agile practices such as stand-up meetings help keep everyone informed and address any roadblock, and don’t forget to encourage the team to make use of your project management tool daily. Things that can help you keep track of the sprint and also execute it include:

• Regular stand-ups: Have short daily stand-ups (15 minutes or less) where team members talk about what they worked on yesterday, what they’ll be working on today, and let the team know if there are any blockers. Particularly for teams with less experience with the sprint format, stand-ups are really helpful.
• Focus on KPIs: Track what you define as the main metrics, such as task completion rate, velocity (how much work is the team completing per sprint?), and more.
• Address blockers immediately: Create a clear process for flagging and resolving blockers, which can be used by the team throughout each sprint.
• Anticipate mid-sprint adjustments: In game development, things change all the time, and that includes your tasks during the sprint. It’s important to ensure the goals remain the same, though, despite any changed that might come your way. For this, preparation helps. Make sure changes are communicated early, designate a decision maker (if not you), and again use prioritization frameworks to decide which tasks remain and priority and which don’t—always keeping your goals in mind. 

This will help you keep track of the sprint as it progresses, and will helpfully make sure everything goes smoothly.

Step 5: Review and Reflect

At the end of the sprint, hold a sprint review meeting to showcase the completed work, followed with a retrospective to discuss:

• What went well?
• What challenges arose?
• How can the process improve in future sprints?

If you’re new to sprints, here’s a quick recap of the differences between a sprint review and a sprint retrospective: 

• A review focuses on the work achieved throughout the sprint, with stakeholders giving feedback and focusing mostly on the work that was (or wasn’t) achieved.
• A retrospective focuses on evaluating and improving teamwork and efficiency, and is limited to the sprint team, without stakeholders. The two main topics here are the process and team collaboration, focusing less on the specific results. 

Something to keep in mind: for smaller teams, it might make sense to just combine the retrospective and the review into one single meeting. If your scope is limited and you don’t have any stakeholders outside the team, then one review with everyone, that can also serve as a retrospective, should be enough. This is particularly important for indie game development teams, for example. 

Either way, if you do just one or both, don’t forget to:

• Schedule the review or retrospective immediately: Ensure the respective meeting happens right at the end of the sprint, when details are still fresh on everyone’s mind. Schedule it ahead of time.
• Include the team (and, if it’s a review, also stakeholders): Encourage people in the team to participate, no matter their role, and rotate the role of facilitator. This will keep everyone engaged, and also make them feel valued. If you’re part of a large team, you can for example do a smaller review meeting to go through all the tasks and a larger show-and-tell one where you present highlights and achievements.
• Document the main takeaways: Make sure to write a summary of the review or retrospective and share it with the team after, to keep everyone on track.
• Focus on the data: Use KPIs such as velocity or sprint goal completion rate to keep the conversation simple and focused, and also to find specific patterns or points of improvement. At Codecks we’ve built our tool with this in mind, and have specific tools for specific KPIs—such as follow-through rate (our Beast Mode feature), team capacity changes (our Capacity Tracking feature) and burn-up chart (our Burndown Chart).

These will make sure you learn from your sprint, and gain actionables for the next one. And voilá: that was your sprint!

Conclusion

Planning a game development sprint can look overwhelming at first—but it doesn’t have to be. By keeping the above steps in mind (and using a tool like Codecks, wink wink), you can streamline the process and quickly define, execute and review a sprint. Whether you’re developing an indie game or managing a large studio project, sprints provide the structure and flexibility needed to achieve your tasks—just make sure to tailor the backlog, the duration and the review of each sprint to your team and its needs.

Codecks was built, from the ground up, as a perfect way to manage game development sprints—keeping all the steps above, and more, in mind. So if you’re thinking of starting sprints, or already doing them, why not sign up and give it a try?