Our Properties: Gamasutra GameCareerGuide IndieGames Indie Royale GDC IGF Game Developer Magazine GAO
My Message close
Contents
Scrum and Long Term Project Planning for Video Games
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest News
spacer View All spacer
 
February 10, 2012
 
Road to the IGF: Lucky Frame's Pugs Luv Beats
 
Analyst questions validity of unusual January NPD results [10]
 
Blizzard opposes Valve Dota name registration
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
February 10, 2012
 
CCP - North America
Animation Director
 
Toys for Bob / Activision
Senior Programmer
 
Toys for Bob / Activision
Lead Programmer
 
Vicarious Visions / Activision
FX Artist-Vicarious Visions
 
Vicarious Visions / Activision
Tools Engineer-Vicarious Visions
 
Treyarch / Activision
Lighting Artist, Cinematic
spacer
Latest Features
spacer View All spacer
 
February 10, 2012
 
arrow Virtual Goods - An Excerpt from Social Game Design: Monetization Methods and Mechanics
 
arrow Principles of an Indie Game Bottom Feeder [20]
 
arrow Postmortem: CyberConnect 2's Solatorobo: Red the Hunter [1]
 
arrow Jerked Around by the Magic Circle - Clearing the Air Ten Years Later [41]
 
arrow Building the World of Reckoning [4]
 
arrow SPONSORED FEATURE: TwitchTV - How to Build Community Around Your Game in 2012 [13]
 
arrow Happy Action, Happy Developer: Tim Schafer on Reimagining Double Fine [9]
 
arrow Building an iOS Hit: Phase 1 [11]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
February 10, 2012
 
Audio Passes: Success Through Layering
 
What the current RPG can learn from Diablo 1
 
Double Fine's Kickstarter Windfall: Will Patronage Supplant Traditional Game Publishing? [9]
 
The Principles of Game Monetization
 
Did DoubleFine Just break the publishing model for good? [15]
spacer
About
spacer Editor-In-Chief/News Director:
Kris Graft
Features Director:
Christian Nutt
Senior Contributing Editor:
Brandon Sheffield
News Editors:
Frank Cifaldi, Tom Curtis, Mike Rose, Eric Caoili, Kris Graft
Editors-At-Large:
Leigh Alexander, Chris Morris
Advertising:
Jennifer Sulik
Recruitment:
Gina Gross
 
Feature Submissions
 
Comment Guidelines
Sponsor
Features
  Scrum and Long Term Project Planning for Video Games
by Clinton Keith [Business, Game Design]
11 comments Share on Twitter Share on Facebook RSS
 
 
December 18, 2007 Article Start Page 1 of 5 Next
 

[The agile methodology known as Scrum is rapidly gaining development credence, and High Moon Studios CTO Clinton Keith (Darkwatch, The Bourne Conspiracy) presents this in-depth Gamasutra article explaining how publishers and developers can benefit through regular, focused iteration.]

Scrum, an agile methodology, is emerging as a powerfully beneficial toolset for building games. The approach of finding the fun through iteration rather than trying to plan and predict it completely up front is appealing to many developers who have repeatedly been surprised by all the unanticipated problems and discoveries made on the path to creating a game.


However, most publishers are too risk-averse to allow a team to not provide them with some form of detailed plan for the entire project. The developer using Scrum may resist this because they want to be able to adjust their priorities to the emerging game. This article addresses these issues of how publishers and developers using Scrum can work together with a long term plan and leverage the benefits of using Scrum.

"Plans are nothing; planning is everything" - Dwight D. Eisenhower

One of the common misunderstandings of agile is that it avoids any long-term planning in favor of only planning a few weeks out. What agile does not do is support highly detailed long term plans up front. Agile methodologies, like Scrum, focus on continual planning for the entire range of the project. Like the iterations on the project itself, agile continually returns to the assumptions of the plan and modifies it based on reality.

One of the principles of Scrum is that the team commits to the amount of work they feel they can finish in small iterations of time called Sprints. These iterations are typically two to four weeks in duration. The results of the last Sprint will be used to potentially modify the goals and priorities of what will be worked during the next Sprint. This allows the goals of the project to "drift" a bit every few weeks. Ideally this drift is for the benefit of the game.

Among the adopters of agile in the game industry, questions are frequently raised about how this "drift" can exist when the publisher demands detailed plans. On the other side, publishers fear that without schedules, an agile team can iterate endlessly and never finish.

Customers Who Want Schedules

Fixed schedules attempt to predict the priorities and a rate of work that can be done ahead of time. Agile is a response to the reality that such predictions aren't very accurate and that we need to continually revisit our plans and adjust them during the entire project. Simply planning things out up front is not enough. The drift inherent with Scrum can be incompatible with these fixed schedules.

Customers often derive a sense of security from schedules. They want to be assured that a commitment is being made to deliver a product they can understand, with a known schedule and budget. It's not something they are going to abandon easily even though they are aware of the problems with fixed schedules. They have seen projects miss those schedules and budgets many times. They need something proven to work better if you want to introduce agile practices to long-term planning.

A Starting Place for Developers and Publishers

A challenge for the game development team using Scrum is to adjust the practices to meet the needs of their customers more closely while preserving the benefits of agile.

Many game developers applying Scrum have adopted what they refer to as a blend of Waterfall and Scrum. This usually means adopting Scrum practices like Sprints, Daily Scrums and Burndown Charts while maintaining detailed plan documents such as schedules and design documents for long term planning purposes.

The Sprint practices for Scrum are very easy to understand and implement while the Scrum practices for long term planning are not as easy to grasp. Some Scrum adopters or customers will not trust abandoning long-term schedules completely.

 

 
Article Start Page 1 of 5 Next
 
Comments

Anonymous
profile image
As far as I have seen and read about agile technologies, especially scrum, I would say that it may be useful for projects that last for couple of months and teams big cca. 10 people. Producing casual games or j2me maybe. Making games for next gen consoles, I do not think so.
Scrum may be ideal for web development company which releases versions of their web applications frequently. I can not imagine how should anyone produce a game which production lasts for 2 years and there are 50 people involved in the game making.

Anonymous
profile image
We been using it here for a few years on AAA games. The overall game design, technical designs, and rough schedule of tasks are completed up front. Each team runs their own sprints. We have bi-weekly demos within the studio and monthly executive reviews. The product owners always have a game to play, and historically have always been impressed (or at least satisfied) with the growth of the project between sprints. It seems to help the bosses feel more secure than other methods, since they get frequent polished updates.

Anonymous
profile image
Too often developers subscribe to a methodology like Scrum as an alternative to solving team problems. Its easier to use How-To guide to project management then creatively assessing the situation, and intuitively building up your own methodology that best fits the team, studio and project.

Anonymous
profile image
I've used Scrum several times outside the game industry where it generally worked very well. I didn't use it inside the game industry until just a few months ago. We are not using Scrum company-wide or with a "customer". Instead, a few departments are using Scrum on a smaller scale just for planning and assigning tasks.

So far, I like the method. At first it felt like we were losing time to daily Scrum meetings and a sprint planning meeting every few weeks. But during the daily meetings, it very quickly becomes clear when a task is too large, a task is taking more time than expected, an individual has too much work (or isn't performing well for whatever reason), how much time outside projects take from our main project, etc. The daily meetings are also a good time to share knowledge and find out when there's a bottleneck in each task (interdependent tasks, waiting for a particular script function, waiting for art resources, etc). Just being able to look at a single board and see the state of the whole project, the tasks currently in progress, who is working on each task, your own place in the grand scheme, and several "next sprint" tasks if you finish early has been helpful.

Anonymous
profile image
"Too often developers subscribe to a methodology like Scrum as an alternative to solving team
problems. Its easier to use How-To guide to project management then creatively assessing the
situation, and intuitively building up your own methodology that best fits the team, studio and
project."

Scrum is not a how-to guide. It's a framework for "building your own methodology that best fits your team, studio and project".

Don't pass judgment on something you haven't tried.

Anonymous
profile image
" Anonymous 18 Dec 2007 at 10:40 am PST
We been using it here for a few years on AAA games. The overall game design, technical designs, and
rough schedule of tasks are completed up front...."

I am happy to hear that. To be honest i am tired of heavy-weight development technologies which can sometimes become so bureaucratic and impersonal. And on the other hand game development should be fun. I really wish that agile ones will find their place in the industry soon.
...
I would also like to know how the work is coordinated in different teams since you run sprints in teams only.

Anonymous from the first post :)

Jean-Philippe Lafortune
profile image
Anonymous from the first post isn't completely wrong. It is commonly used in casual game or short development (ie: 6 months). I didn't know about Scrum until 2 weeks ago but as a Manager I have been producing games this way. In a 6 month dev, there is a short period between each steps or milestones and communication with the customers are crucial. After RFP is accepted, project starts. Submission of Detailed (not so detailed) Schedule and Design Document should occur 2 weeks after project starts. We then submitted playable prototype1 two-three weeks later, prototype2 and 3 soon after so we agree on gameplay and fun factor. Next thing you know your half way through the project. You finalize the visuals and its already alpha release. We didn't meet on a daily basis but on Mondays and Fridays with a casual Wednesday lunch with all team members.

Now I know big studios whose using Agile method on starting AAA project and I'd really like to test it out on a large scale. It the only way to get your client involved in the choice of feature to be develop according to reality-certainty as opposed to uncertainty of long term planning.

I just wander how can Agile solve the problem of cascading projects and efficient resource assignments. I can picture a new project to be started with this methodology but what about the second one that's starting the very week after the first one when you have a team of over 50 people that you need to assign to something constructive?

Cheers,

Bingaloo Pravanati
profile image
Anonymous from first post is wrong in the sense that Scrum can absolutely be used by big teams on "next-gen" projects. High Moon studios - the article's author's studio - is a good example of this.

Clinton Keith
profile image
There are a large number of big, AAA projects using Scrum. The most recently released one (AFAIK) is Mass Effect.

Christian Torrico
profile image
What i don't understand about Video Game development with Scrum, it's that in software development each sprint includes testing tasks to find errors and correct them, right?

But i read some time ago in Clinton's book, that for video game projects there was a post-production phase. So... we do testing later like in waterfall? I mean... sounds weird. Could somebody explain how this works?

Brian Perry
profile image
I suggest you take a project management course. I just finished one and it will teach you a lot if your interested in starting a company or managing someone else's game. Agile and Scrumm are just two different ways to do generic project management. You have to learn the basics first.


none
 
Comment:
 




UBM Techweb
Game Network
Game Developers Conference | GDC Europe | GDC Online | GDC China | Gamasutra | Game Developer Magazine | Game Advertising Online
Game Career Guide | Independent Games Festival | Indie Royale | IndieGames

Other UBM TechWeb Networks
Business Technology | Business Technology Events | Telecommunications & Communications Providers

Privacy Policy | Terms of Service | Contact Us | Copyright © UBM TechWeb, All Rights Reserved.