Agile development methodologies within the game industry – Part II – KanBan

KanBan within the gaming industry!



KanBan vs. SCRUM

KanBan, to the naked eye, can look a lot like SCRUM, and you may think; “Why should I use KanBan when I can use Scrum?”, and vice versa. Kanban has some functionality that SCRUM does not, and SCRUM has some functionality that KanBan doesn’t have.

I think I started off making you guys confused, so let’s dive into KanBan, instead of comparing KanBan and SCRUM!

What is KanBan?

KanBan, like SCRUM, is another agile development methodology. What exactly did “agile” mean? Agile means the following:

  • We are open to change
  • We focus on great teamwork and open minds, instead of huge plans
  • We work in iterations and deliver after each iteration
  • We make sure that every one in the team are knowledgeable with the progress of the project

These are some of the main values of agile development.

The KanBan workflow

KanBan has a specific workflow that can be followed. Just like SCRUM, KanBan has a board at which the team can look at to see what other team members are doing, together with change their own task once a task has been finished. Such a board could look like this:

KanBan Board

Let’s go through these steps. First, we have the Pending column. This is where you place your user stories (more on what they are later), that you need to implement at some point. This could be character animation, environmental sounds, or resource gathering within your game.

The next step is the Analysis column. This is where your user stories gets analysed, and where you define your user stories. Let’s take the environmental sounds; Where is this game happening (city, forest, maybe an abandoned island)? What sounds are needed (birds, cars, wind)? How long should these tracks be (1 minute each, 2 minutes each, maybe just loop them and run them constantly)? In the end, there shouldn’t be any questions left, without an answer. When the analysis of a task is done, you move the task to the Done row within the Analysis column.

The next step is the Development step. This pretty much explains itself. Whenever you decide to start developing on a certain task, you move the task from the Done column in the Analysis section, into the Doing column in the Development step. Make sure to follow the definition that has been made within the Analysis column.

Next step is the Test step. KanBan says; “NEVER deploy anything unless it has been tested thoroughly!”. Before you deploy ANYTHING into the actual game project, you need to make sure that everything works. Testing the specific task with other features of the game of course isn’t possible, but you should make sure that the task (character animations) works on it’s own, before deploying.

Talking about deploying, this is the next step; the Deploy column. Once a task has been analysed, developed, and tested, you can now go ahead and deploy this into the game project. Congratulations, you have just completed a KanBan workflow!

User stories

I mentioned user stories very shortly within the previous section of this post. User stories and tasks are not the same. User stories can be the following:

  • Character animations
  • Environmental sounds
  • Resource gathering

And task can be these:

  • Character animations
    • Rigging
    • Define movement (run, walk, crouch, etc.)
    • Speed
  • Environmental sounds
    • Nature sounds
    • Looping sounds
    • Footsteps
  • Resource gathering
    • Inventory system
    • Convert foliage to blueprints (UE4)
    • Add health to blueprints
    • Add respawn timer

Basically, within a user story you can have multiple tasks defining this specific user story

User stories are usually made in the beginning of the project, but more can be added along the way, if functionality changes are made.

Work-In-Progress limitation

Unlike SCRUM, KanBan has a limitation off how many tasks may exist in one column. This is done to prevent overproduction and this will reveal eventual bottlenecks within the KanBan flow. Let’s say that the developers can develop 10 user stories each week, but the testers are only allowed to test 5 user stories per week. Here’s the bottleneck; eventually the testers will have a huge amount of user stories just waiting for them to finish, but the testers are only allowed to test 5 user stories per week.

This is the real strength of KanBan, as you can quickly spot the bottlenecks and act accordingly to these.

That’s basic KanBan

That’s…. basically it. KanBan is incredibly simple to use, and yet it is extremely strong when used. Within this post, I have tweaked KanBan for usage within a game developing environment.

This is a very simple explanation of KanBan. If you wish to know more, or get a more detailed explanation, there is plenty of articles on the web about it + books in the library.

I hope this post has helped you understand KanBan and the basic usage of it.

Next time we’ll talk about Extreme Programming. Hope you enjoyed this post, and thank you for reading!




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s