Now that we have our game split into neat little pieces, tasks, what do we do with them? Game projects often last for months or longer and we need ways to manage everything. In this lesson, we'll get familiar with two project management frameworks: scrum and kanban.
In Scrum, work is done with a co-called iterative-incremental approach. This means that features (like player movement) are refined again and again during the time they are in production. This is called iteration. In Scrum, the product is created in small, complete pieces, increments, thus the name iterative-incremental approach.
The project is divided into sprints. Sprints are fixed, repeating time intervals lasting from one to four weeks. During a sprint, your goal is to build one functional part of the project
One of the core goals in Kanban is to visualize the work. This is done with a Kanban board like seen in the picture above. You might recognize it from HacknPlan, which uses quite a similar planning board. Each post-it note is a separate task.
In Kanban, these tasks are called user stories, and the tasks may be described from the point of view of an end-user; As the hero, I want to wield a powerful sword so I can defeat the enemies and gain loot. These user stories are collected in the backlog, and when it's clear that the desired features can be implemented and the details are clear, they can be moved to the to-do column.
Unlike in scrum, there are no sprints in Kanban, but the work flows constantly. The number of tasks in the to-do -column is limited; each team member should work on one task at a time.
The Scrum Master makes sure that the team follows the agile principles and helps the development team and the product owner maintain good habits. They make sure that the sprints are structured accordingly and facilitate meetings related to running the project. Kanban does not have any roles by default, so having a Scrum Master (or often an agile coach or service delivery manager in Kanban) is optional.
Product owner is a person responsible of the project's backlog. They go through the tasks, organize them, and communicate to the development team about the tasks that need to be completed to achieve a certain goal. They represent the customer and stakeholders. In Kanban, this (optional) role is sometimes called the service request manager.
The development team is the team that makes the product. Programmers, designers, and artists make up the team. In scrum, the optimal size for this team ranges from 3 to 9 members. A large development team can be divided into smaller teams to function better with scrum. Kanban does not put limitations on the team size.
Scrum and Kanban are good starting points if you've never tried the agile approach to software development. But as you get to know your team and the project, you should adapt your workflows accordingly.
There is also a combination of Scrum and Kanban that combines some functionalities from both. This combination is called Scrumban. In reality, teams rarely use pure Scrum, Kanban, or some other methodology, and most have their own mixes of guidelines, roles, and meetings created by combining different methodologies.
Which method do the following characteristics fit?
What do you think of agile development? Did some strategies seem better than the others? Remember to keep an open mind and try different things during your career, you never know what might work!
Now, let’s move on to project planning.