Scrum and Long Term Project Planning for Video Games
December 18, 2007 Page 3 of 5
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.
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.
Page 3 of 5