Skip to content

5 Types of Game Production Meetings

In our recent Production Workshop, we touched briefly on the important role of producers asking the right questions and creating time/place for check-ins. To reiterate, production is about finding problems that are threatening to impact the rest of the team, solving them and preventing them. This includes production problems like projects being late, feeling the need to crunch and more.

This list of the different types of check-ins or meetings should serve as a useful resource for indie game dev teams, especially those without a dedicated producer. They’re listed in rough order of importance, although they have different purposes and will achieve different things. Feel free to pick the ones that will work for your team! Try and find a spread of focus for your meetings— some should be focused on day to day, some should be focused on medium term goals, and some should be aspirational and long-term focused. Without further ado, here are a series of starter check-ins that you can run with your team.

An illustration of several people panicking at the table.
Having effective check-ins will help prevent major production problems!


Standups (also known as Daily Scrum in Agile software development) is a short daily meeting, which allows team members to raise any problems that they are facing, and ensure the wisdom of the team is available to them to solve these problems.

The goal of a standup is to ensure that each team member has at least one opportunity throughout the day to speak to the rest of the team, and raise anything they think is worth raising. 

This can be simple things, like:

“I’m not feeling too well and might be sick this afternoon, so I might not be able to get to that new UI update”,

or more complex things, like: 

“I’m nervous about the work I’ve got on my plate next week— I might have bitten off more than I can chew”

Or, more commonly, it will be simple and small things, like:

“This new inventory system is still underway – it’s taking a little longer than expected, but should be ready soon.”

Having a daily meeting can seem a little scary, especially for meeting-light teams, so it’s important to note that Standups are time-boxed. Standups should run for no longer than 15 minutes in total. It’s meant to be a quick check in, and if there are any major problems that require discussion, those team members can continue to chat after standup. This is so we don’t disrupt the work time for other team members who may not need to participate in that conversation.

Once the team has been doing standup for 2 weeks or so, it can often get stale. If your team gets into the habit of answering off of the cuff, without thinking about the actual questions, you might need to mix it up a bit. Try changing the questions you ask, the order in which you ask them, or other things about the process. Alternatively, try thinking about the production problems that are facing the team and target your standup questions to aim to reveal any of those kinds of issues earlier.

An  illustration of a hand changing up the blocks of the standup format.
Prevent standups from going stale by mixing up the format.

Sprint Planning

Sprint Planning meetings are to set a clear and achievable goal for your team to accomplish. A mini milestone, if you will. In a sprint planning, your team will meet and set a clear goal for what to achieve in the next sprint. This helps give structure to what the team will be working on in this period of time.

It’s worth briefly introducing the concept of a ‘sprint’. In Agile software development, a sprint refers to a fixed unit of time (usually 1-2 weeks). This amount of time is short enough that you can effectively plan for it without too many unexpected disruptions, but long enough that you can achieve larger pieces of functionality.

These meetings are especially useful if your team is finding that there are a lot of unclear priorities, or the team doesn’t have a solid understanding of what things will be worked on across the team on a medium term basis.

illustration of a trail that leads to a flag. A metaphor for milestones.
Think of sprint planning as mini milestones!

Sprint Review

Sprint review is a meeting that occurs at the conclusion of a sprint (see Sprint Planning above for more information on what a sprint is). At the end of your sprint, the team looks at the sprint goal, and sees if they achieved it. They also look at the specific work completed, giving any feedback, or identifying any future work that will need to be completed.

These check-ins are an opportunity to look back at all the work completed during a sprint, and inspect and celebrate it. If your team doesn’t have good insight into what is being completed over time, or there are pieces of work that need a lot of review or iteration, you might find Sprint Review helpful.

Sprint Review should be done in conjunction with Sprint Planning— they go hand in hand.

illustration of a hand dragging cards around a Kanban board.
Sprint Reviews are for checking on whether sprint goals have been achieved.

Team Retrospective

A retrospective gives a team the opportunity to discuss how they are going with completing work. As opposed to a review, which examines the work done, a retrospective is there to allow a team to focus on the processes that they have, and the way that they are working together.

During a retrospective, the team will gather and discuss issues that are preventing them from getting their work done as efficiently as possible. The team will also discuss things that went smoothly recently, to ensure that positive processes and changes are also captured and discussed.

Then, the team will look at possible process changes that can be made to address problems or maintain positives. The team will choose a small number of these improvements to implement before the next retrospective.

For examples of retrospective activities you can run, this retrospective kit from Spotify and this site should be particularly useful!

An illustration of a hammer labeled process hammering a rock labeled "work done".
Retrospectives are for discussing processes, not the work done!

1-on-1 Check-ins

1-on-1 check-ins are a tool for you to speak to your team individually, and ensure that they have the opportunity to raise feedback in a more personal environment. They also give you the opportunity to provide feedback to your team.

If you’re finding that you don’t have a solid grasp of what types of work your team members care about, or you’re struggling to stay on top of potential problems amongst your team, then 1-on-1 check-ins might be the right tool for you.

This can be the most varied type of meeting that you will have with your team. Ideally, you should set a goal for the specific thing that you want to achieve with these meetings. At a high level, your goal should be to ensure that each team member has an opportunity to raise problems in a safe environment, or just to discuss what’s on their mind.

These meetings are also an excellent way to discuss things like career goals and growth, which types of work are interesting to your team members, and other things which are excellent to ensure that you have a solid grasp of what your team members care about or are thinking about.

An illustration of two people talking to each other.
1-on-1 Check-ins are important for making sure you and your team get regular feedback.

To conclude, indie game development teams are understandably small and lean, but key production decisions such as what mix of meetings/check-ins you have are critical to getting your game out there. We hope this list of meetings you can run with your team were helpful in inspiring you to be better producers!

We hope you enjoyed reading this! Have a question or want to chat more about game development? Reach out to us!

Other places you can find us:


Leave a Reply