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.
- First part: Scrum and videogames 1: Introduction
- Second part: Scrum and videogames 2: The Sprint Meeting
Our daily routine
At The Game Kitchen, every team member starts their day in HacknPlan, reviewing which are their pending tasks. After that, we have a “daily meeting” using our Discord server, where everyone has to read each other’s comments and write one answering the following questions:
- What did I do yesterday?
- What am I going to do today?
- What do I need from someone else?

From that last question, we can see what the dependencies between members are, so if you have any or someone else has one with you, you both have to organize yourselves trying to add that pre-requisite to the planning of your day.
After that, every team member picks up their first HacknPlan task and moves it from “Planned” to “In Progress” in the kanban board. When you think you finished your task and it is committed to the code repository, we come back to HacknPlan and move it to the “Testing” column. Last, but not least, we need to ensure the task is assigned to the person in charge of testing it, who is normally a designer (we don’t have testers in the team yet).

New increment and preparation for the next Sprint Meeting
The importance of a good integration
During the sprint, the team members have been focused on their own stuff, and it is important that every element introduced by each of them work well as a whole. In order to achieve that, the team needs enough time to perform a good integration.
What we do is sacrificing a production day to integrate everything and prepare the next Sprint Meeting. The last day of every sprint, which is normally a Friday, we leave it exclusively for ensuring the correct integration of everything that has been added to the game, quality improvements, and “do homework” to be able to properly determine the tasks for the next sprint during the next meeting.
Generation of the candidate increment
Continuing with the same example, if the last day is Friday, we try to have a candidate build by Thursday evening. We assume some minor stuff is gonna fail on that build, which will be reviewed on Friday, making whatever fixes are necessary on the go until everything works as expected. Remember that it is essential the whole increment is playable so everything can be analyzed.
Peer review
We also use the last day for the team to review each other’s work. The goal is finding and proposing improvements in the way each feature has been implemented, with the idea of detecting potential future issues. We’ll look for things such as:
- Undocumented code.
- Quick code that does not take scalability into account.
- Sloppy code.
- Bad nomenclature.
- Misunderstandings in requirements.
Some of the issues detected can be quickly fixed that same day; otherwise, the requirement is written down to be resolved during the next sprint.
The increment outside the build
Sometimes, there is interesting progress that is not achieved in the game build, like narrative, concept art or music demo tracks. It is important to remind those members they prepare something to show so they can transmit that progress to the rest of the team. This could be something like exporting some of the PSD files to JPG, render a 3D model, or even preparing a slideshow when there is a more complex design or concept to show.

Increment history
We name our Sprints with the YEAR-MONTH-LETTER nomenclature, so 2019-1-A would be the first sprint of the year. One or two days before the end of the sprint, we create a folder in our version control system called something like “\trunk\scrum\2019-1-A” that we will use to store a copy of the build generated on that increment, audio and art sketches, and other document needed to show the progress of the project.
Besides it is convenient having all the material for the meeting in a single place, is also useful to generate marketing material in the future, when the release date is closer.
Is each team member responsible for creating their tasks?
Do you change a task to completed after you are done with unit tests or integration testing?
Thanks for sharing your experience!