Agile development methodologies within the game industry – Part I – Intro and SCRUM

Development methodologies are just as important!



Yes, I did just say that…

The game itself is what the players value, no doubt about that, but the development methodology is what your development team values the most.

Having structured development agreements and rules, can help your development teams efficiency.


Development methodologies?

If you read the headline, and the section above this one, and you have absolutely no clue what I’m talking about, don’t worry. I’m going to cover relevant development methodologies within this series, but first of all What is a development methodology?

A development methodology is a tool that helps development teams, develop their software, website, plugins, games, and much much more. These methodologies creates a structure around the project. Let me give you an example;


  • Lets the development team break down the project assignments into smaller tasks
  • Lets you see what other developers are working on
  • Provides estimates for specific tasks
  • Gives you an overview over the teams efficiency
  • Daily meetings in which you will be updated on the current progress of the project

This is just one of the many methodologies, and we’ll talk much more about SCRUM later in this post.

Why do you need a development methodology?

Imagine yourself starting a new project. Let’s say you wish to make an open world RPG MMO game. After deciding what the game is about, you start hiring people to work for you. As you pay these people a fair amount of money, you expect them do deliver high quality project assets.

Now imagine that you found every single member of the team; a 3D modeler, a programmer, someone with knowledge of networking, a level designer, and so on…

Now it’s time for you to hit the green button and say the golden word: “GO“.

Everybody starts developing, modeling, mixing audio, recording, everything goes nuts! Already during the first week, you might encounter a problem that I’d like to call;

  • Rule #1: Never have two people working on the same task

If you didn’t plan correctly, this could be a very realistic problem. A programmer starts working on character movement, so does another. The first programmer pushes this to a remote source control such as GitHub. After 2 hours, the other programmer pushes this as well, creating a conflict within the source control, and there you go, problem number 1.

This could happen to the 3D modelers as well, the level designers, the audio engineers. Well, everybody, and as you are paying these people, you DO NOT want to struggle with these issues, as it’s a waste of money and you won’t get anything produced.

This is where development methodologies come in handy. Let’s me name a few of which I know and treasure:

  • SCRUM, as already mentioned
  • KanBan
  • Unified Process (UP)
  • LEAN
  • Extreme Programming (XP)

These are just a few of the many methodologies, and you can even mix these as you’d like. You can take some of the values from SCRUM that you like the best, and that fits your project the best, but you can mix these with the values from KanBan that you like the best: Tadaaaah! You’ve created ScrumBan!

In this series I’m going to focus on three of the methodologies mentioned above; SCRUM, KanBan, and Extreme Programming. For this post, we’ll stick to SCRUM.


SCRUM; What is it?

SCRUM is a methodology that gives you a neat overview of what to do, was is currently being done, and was has been done already. At the same time, you can see what other people are doing at the moment.

Let me quickly mention the values of SCRUM:

  1. Lets you break assignments down into simpler tasks
  2. Daily meetings to update everyone in the team
  3. High efficiency of the production teams
  4. Everyone knows what everyone is working on
  5. Small iterations together with a product review with the stakeholder/customer/product owner
  6. A scrummaster needs to be chosen to ensure that SCRUM is working within the team

These are the main values of SCRUM. Let’s break these down even further.


The daily SCRUM meeting is what we call “Daily SCRUM”. The daily SCRUM is normally held in the morning whenever the team assembles. This meeting is a standup meeting, as it would take longer to find chairs, than to actually have the meeting. During the meeting everyone should answer the following questions:

  • What did you do yesterday?
  • What are you doing today?
  • Are you having any problems with anything at all?

Should the case be that someone has a problem, someone in the team should man up and say; “I’ll help you after the meeting!”.

The daily SCRUM ensures that everybody knows how far you are with the project, they know what everyone will be doing during the day, and they know that they can get help if they have a problem.

Note: the daily SCRUM can be held at any time of day, but you usually have the daily SCRUM whenever the team assembles.


The SCRUM board could look like the following:

SCRUM board of a 3D modeling team

This board is where you can see what other people are working on. The SCRUM board gets defined whenever you create a new sprint (we talk more about sprints later).

Let’s say you have 76 tasks for the entire project. You won’t be able to finish all within one sprint. You can have a sprint that last 2 weeks, and with this in your thoughts, you choose what tasks you wish to finish during these two weeks. Perhaps you have 5 huge and difficult tasks? These tasks might take a while to finish, therefore 5 is enough. Let’s say you have 23 tiny and easy tasks. Is this the time to implement these into the game? Fine, take these 23 tasks.

What tasks to choose for the sprint is entirely up to you, as long as it makes sense, and you have the time to finish these. This is where the estimate of tasks come in handy.

SCRUM Sprints

I’ve mentioned “Sprints” a few times, but maybe you still don’t know what a sprint actually is. Allow me to clarify.

As SCRUM is an iterative working methodology, we need to make one huge plan of smaller plans. It works like this:

sprint plan

As you see above, we have one huge plan with 3 smaller plans. These smaller plans are what we call “Sprints”. We have a few numbers that we need to go through:

  1. Sprint planning
  2. Sprint itself
  3. Sprint review

In the sprint planning phase, you plan the sprint that you are going to work on next. During the sprint itself, is where the tasks are being developed. The sprint review is a meeting with the stakeholder/customer (in gaming industry, I’d say this was the project leader, or “the man on the top”).

During the sprint review, the team show what they’ve done, get feedback, and then start planning the next review. BUT, before the team plans the next review, they need to have what we call a “Sprint Retrospective”.

During the sprint retrospective, the following questions should be answered by the team:

  • What went well during this sprint?
  • What didn’t work that well?
  • Can we improve? If yes, how?

Sprints can vary in length of 2 weeks, to 6 months. This is completely up to you.

Should any changes to functionality arrive during the sprint, we need to implement these changes in the sprint, or into the backlog. This is an agile development methodology, which means that WE ARE OPEN TO CHANGE.

Note: In my personal experience, shorter sprint (2 weeks or so) seems to work the best, and have the highest efficiency together with the highest success rate of the project as a whole.

Estimating the tasks

Consider the following:

You have 76 tasks and 7 sprints consisting of 2 weeks each. You know that every person will be working 36 hours a week (normal working hours here in Denmark). Let’s say you have 5 programmers:

5 * 36 = 180 -> every sprint, the programming team has 180 hours available. Lets say you have these 4 tasks:

  • Implement character movement (62 hours)
  • Implement underwater post process effect (47 hours)
  • Implement ability to shoot and show a projectile (37 hours)
  • Implement basic enemy AI (34 hours)

62 + 47 + 37 + 34 = 180. These tasks are therefore perfect for a sprint. Don’t add more tasks, don’t add less.

The estimates of the tasks are done by the team in the very beginning of the project. These are NOT done by the project leader, but by the team, as only they know how long each task will take. Everybody in the team needs to agree on the estimates.

Note: Notice that I said in the beginning of the “project”, not the sprints.

When the team is done estimating the tasks, these tasks are put into what we call the “Product Backlog”.

Product Backlog

The product backlog is where ALL tasks are stored, together with the estimate of these tasks. Whenever you are to plan a new sprint, you take the existing tasks from the product backlog. Whenever a task has been finished (and approved of course), these are to be removed from the product backlog. That’s basically all I have to say about the backlog.

Roles in SCRUM

SCRUM has various roles that needs to be filled in the beginning phase of the project. SCRUM ha the following roles:

  • The team
  • the Scrummaster
  • The product owner
  • The stakeholders/customer (aka. the project leader)

The team consists of the actual development team. Very basic, nothing there.

The Scrummaster however, is the guy that runs around like a confused chicken. That did not make any sense to you did it? Let me clarify: The scrummaster is the guy that makes sure that SCRUM is working in your project. He’s the guy that makes sure everybody meets to the daily SCRUM, he’s the guy that makes sure to help you with your problems (if he can’t help you himself, he’ll find someone who can), and he’s the guy that makes sure everybody knows what to do next.

The product owner is the “voice of the stakeholder”. The architecture could be like this: you (as project leader and “king of the mountain”) -> product owner (head of programming) -> the programming team. So if you have questions for the big bad boss, ask you product owner first.

The stakeholders are the people which you are developing for. This is quite difficult to put into my view on SCRUM within gaming industry, so I’m actually gone leave that one out, but for good times sake, the stakeholders is just a more fancy word for customers.

That’s basic SCRUM

With the knowledge you gained from reading this post, you should be able to use SCRUM in future project. SCRUM is used to ensure quality of the product together with team management.

Within this post I’ve tweaking the basic SCRUM principles so that you and your team can implement this directly into a game development project. To learn more about SCRUM in further details, and in professional environments, Google is truly your friend. You can find endless articles on SCRUM on the world wide web.

Let’s quickly go through what we’ve learned:

  • We’ve know what daily SCRUM is all about
  • We’ve learned what the SCRUM board is, and how to use it.
  • We know how to construct SCRUM sprints, how to complete sprints, and how to review the sprints.
  • We know how to estimate our tasks as a team.
  • We’ve learned what the product backlog is.
  • We’ve learned the roles of SCRUM

If you have any questions or corrections to my post, you’re more than welcome to post these in the comments below.

I hope you learned how to use SCRUM, and I hope you enjoyed this post.

I’ll talk to you guys next time, where we’ll talk more about KanBan!




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