For mobile games, like just about anything else, getting your project done efficiently and on time is essential for success. At GOSUB60, we’ve decided to implement the agile framework known as Scrum to improve our development process, and thus increase our efficiency. Scrum has been used in software development for about 15 years, but it has only recently come to the games industry. I thought it might be useful to examine how Scrum applies to developing mobile software, and the ups and downs of our transition to this process.

Scrum approaches software development differently than most traditional project management processes. Instead of trying to define all the tasks and requirements for a project up front, Scrum uses very short development cycles and frequent inspection to adapt the development process as the project progresses. There are two primary reasons for this. The first reason is that software development is a complex enough a process that it is impossible to predict all the tasks for a project beforehand. The second reason is that the software business is changing at such a rapid pace that it is essential to be able to adapt to the changing business conditions. Scrum tries to account for this by defining a project by a Product Backlog, which is a prioritized list of features and requirements for the application. This backlog is then developed in very short increments, known as sprints. The output of a sprint is a complete slice of functionality. The Product Backlog can be reprioritized constantly so that the highest priority features are always being developed at any time. Because each sprint ends with a completed slice of functionality, the software can be shipped at the end of any sprint, whenever it makes the most business sense. For more details on the Scrum process, check out

So why use Scrum for creating mobile games? I think Scrum offers several advantages. Scrum welcomes change; that’s its mantra. Mobile games are subject to more change than a traditional video game because the platforms are in constant flux. New devices appear every week with different specifications, and Scrum allows you to add or remove features as necessary to reflect the set of platforms.

In Scrum, a product is never finished. Products are released, but items will always remain on the Product Backlog. For a mobile game, this is especially appropriate because new versions are always being submitted for new devices. If the business conditions change such that new features need to be added for a new phone, Scrum can handle that very easily.

Scrum relies on repeated feedback from stakeholders and team members alike for its inspect and adapt cycles to work. Mobile games are easy to compile and distribute for feedback, making it easier to solicit feedback from a greater number of people. This means that the process and the product can be refined more easily.

Scrum is a good fit for mobile game development, but it’s not perfect. Next time I’ll address some of the challenges of applying the Scrum framework to mobile game production.