Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Scrum and Long Term Project Planning for Video Games
View All     RSS
July 14, 2020
arrowPress Releases
July 14, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Scrum and Long Term Project Planning for Video Games

December 18, 2007 Article Start Previous Page 3 of 5 Next

Rolling Milestone Schedules

Most publishers acknowledge the problems with trying to create detailed schedules and plans. As a result, many development contracts these days acknowledge this by having a rolling level of detail for future milestones.

An example of this would be a contract that specifies a high level of detail for the next milestone with the level of detail dropping for milestones that are further out. As the project progresses, upcoming milestone details are fleshed out with more detailed promises of what the team hopes to deliver.

These "Rolling Milestone Schedules" start to look a lot more like the Sprint cycles in a traditional Scrum project. They still offer little room for the backlog to change within a milestone/release cycle, but the team can grow the amount of change the customer is comfortable with by growing their level of trust and confidence with the practices.

Introducing Change to the Customers

In order to allow more change to occur during the milestone, a development team has to address the relationship with their customers, especially the publisher. Let's start by looking at how publishers often view their external developers. There are a number of tacit assumptions that can exist on the publisher side:

  • We have to have detailed schedules so that the developers will work hard and we'll get our money's worth out of them.
  • The only control we have over the developers after the contract is signed is the milestone payment, so we have to get all our details for the game in up front.
  • Because the developers can't afford to miss milestone payments they are not open to our change requests during development, so we need to get all of our requests into the design documents.

This does not foster a very collaborative working relationship between the publisher and the developer and it's not going to change overnight. The customer and developer need to build trust slowly. Fortunately, the principles and practices of Scrum are designed to build trust. For example, at the end of every Sprint there is a Sprint Review where the team and the customers can play the latest version of the game and influence the priority of the work that can be done during the next Sprint. If the customers attend these reviews they will see a number of benefits:

  • Improved velocity of progress every Sprint.
  • Regular working versions of the game they can play.
  • The ability to offer suggestions and feedback that is taken seriously by the team and affects the next Sprint demo they will see.
  • Artifacts in the form of the task-boards and burndown charts that demonstrate daily progress.

While you may take away some of the sense of security of the customer without detailed schedules, you give working versions of the game on a frequent basis that demonstrate -- not predict -- progress. This should help them retain their sense of security.

The largest benefit to the customers is an increased level of productivity and flexibility. As the team improves its velocity, it should have some slack built in to add things that the publisher might want to see added or improved in the period of a few weeks. This benefit can become the biggest selling feature for Scrum and encourage the customers to allow more slack in the immediate milestone definition for even more change. Once the cycle of feedback and adoption/demonstration of changes is established, then trust grows.

Handling Production Debt with Scrum

One of the main differences with game teams using Scrum is that we don't release a "potentially shippable version of the game" every Sprint. The reason for this is that games must ship with around 10 hours of gameplay. This requires a great deal of production assets to be created and tuned.

Since production assets are highly dependent on game mechanics and technology, most of these final assets are not created until we know exactly what the game needs. As a result, game teams using Scrum still divide their projects into two phases: pre-production and production. This avoids wasting a lot or time and effort producing the wrong assets too early.

The production of a minimum number of hours of content is a major constraint on how iterative and flexible long term planning can be on a game development project using Scrum. Game projects are often faced with a 12+ month production "debt" of work to do and a fixed shipping date based on holidays or movie release dates. The combination of these two often leads to the demand for long, detailed schedules.

Article Start Previous Page 3 of 5 Next

Related Jobs

Disbelief — Cambridge, Massachusetts, United States

HB Studios
HB Studios — Lunenburg, Nova Scotia, Canada

Senior Game Designer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Gameplay Designer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Gameplay Designer

Loading Comments

loader image