This article is a collaboration with Mauricio García, CEO and Producer at The Game Kitchen (The Last Door, Blasphemous). You can find his original article in Spanish here.

At The Game Kitchen, we started to apply Scrum 7 years ago, and we have been making it our own since then: we only keep those practices that make the project flow and the process enjoyable.

What is Scrum?

I don’t wanna go on for too long explaining the basic concepts of Scrum because they’ve been described enough everywhere on the internet, but at least we can go over what, in my opinion, are the pillars of the methodology:

The main problem Scrum solves is the following: considering we, humans, can’t predict the future, any planning done at the beginning of a project is always inaccurate. Even worse, in a long project, as time passes, the planning is being more and more useless and improvisation takes over. Instead of considering the development as a unique process of several months, the methodology proposes to cut that long period into several small ones (typically a month). Those periods are called Sprints.

The methodology proposes a “protocol” to develop during every sprint, that will be repeated over and over again until the project is finished. The key piece of this protocol is the Sprint Meeting that takes place between the end of a sprint and the beginning of the next one. The goal of this meeting is planning the next sprint, having a realistic and clear overview of the status of the project (after the previous sprint) and the new requirements, opportunities or needs that arose during the process.

The importance of increments in game development

In every new sprint, you should dedicate some effort to add more content and features to the game. But it is also very important dedicating some percentage of that effort to iterate over the functionality that is already in the game but doesn’t work at the expected level yet. In order to decide which elements are we going to put effort into during the new sprint, it is of crucial importance starting the meeting by playing the game to see its real current state. The last build of the game done after the previous sprint is the increment itself.

It is important to ensure the increment contains a demonstration of all the features developed during the sprint. In order to achieve that, is key the full team go from “adding stuff” to “checking everything is there and working” mode with enough time. At the end of the article, we will go into that with more detail, like the preparation of the next sprint meeting.

Collateral benefits of the presentation of the increment

The team members always tend to work focused on their own tasks. This makes them lose the notion of what is going on beyond their own computer screens. After one or two weeks, it is pretty normal nobody has any idea about how much the rest of the team contributed or the progress made to the project globally. The presentation of the increment is a great moment for all the team members to get a full overview of the real status of the project, and we normally see everyone involved feels motivated seeing what the whole team has accomplished.

Planning and execution mindsets

We learned from experience the real productivity is reached when everybody arrives at the office and they undoubtedly know what their tasks for the day are, prioritized by importance or dependency factors with other team members. On the contrary, if after every task we enter in the mental state of asking ourselves… what should I do now?… then we are probably operating below capacity.

In order to achieve that, we have to let our planning as clear as possible during the sprint meetings:

• Sort the tasks by importance.
• Sort the tasks by dependencies with other team members:
  • The audio, art, and programming tasks have clearly defined design requirements.
  • Level design tasks have their art, audio and programming assets already available.
• Define atomic and precise tasks.

Sprint duration

Our sprints normally last:

• One month: Only during the two or three initial months of the project. These stages require a lot of investigation and experimentation work and having an executable increment to work with is not possible anyway, so there is no benefit in having frequent meetings with the whole team.
• Two weeks: After the initial stages, most of our sprints are this long. We found it is the perfect balance between the amount of production time spent in meetings and the quality of the planning.
• A week: When we are close to finishing a build for a delivery. The nature of the tasks requires more increment and closing features already present, instead of introducing new ones.
• One day: For the last days before delivery. We playtest the increment and decide what’s the best strategy to take advantage of the time to have the best possible build at the end of the day.

Read the second part: Scrum and videogames 2: The Sprint Meeting