Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All
View All     Submit Event

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

Perspectives on Scrum
by James Hofmann on 01/12/10 11:13:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


I've been keeping my head down lately trying to finish my first commercial independent project, Deep Sea Descent. Currently expect it to come out sometime late February or maybe early March. I was going for early February, but pushed back my dates a little.

Today I rode the bus up to the UC Santa Cruz campus for somewhat of a fun diversion - dropping in on a game design class. The specific class I attended on this occasion was "Game Design Studio 2," led by the well-known Michael Mateas. The class doesn't have a heavy lecturing component, but this particular session was on Scrum, and I thought to myself when I saw it in the course listing, "Hey, I've put in about 200 days or so of Scrum standups. I know how it works in a 'real world' environment, maybe I can contribute a little."

But instead of offering up-front to contribute as an outsider I just posed as a student and asked questions in such a way that it forced to the forefront some issues that I knew were important. It was more fun that way. Mateas did just fine and recommended that if any of the problems I presented came up, the students should see him for advice. :)

But to get to the point, the lecture and Q+A let me reflect on a problem I have with Scrum's sprint planning mechanisms - that sprints are supposed to start with a certain direction and stick to it for the duration. The problem I have with this "unchanging direction" philosophy comes, I think, from the subjective elements; if it's purely technical tasks, it works. It's when that isn't the case that problems arise. The idea that you can research some gameplay mechanic or level concept one day, and then it's "done," for example, is one that I found plaguing my design estimates.

It always worked out that one big feature would be planned, e.g. "combat," you designed and prototyped it as much as you could, and much later, it would recieve a final implementation. You would make near-zero progress in everything related to that feature regardless of time allocated, right up until the final implementation hit, and then afterwards you'd have to pick up the pieces and cobble together some gameplay from whatever was there, because it would never turn out to be exactly what you thought it would be. Planning was disrupted at every turn.

So on any given day I often had no idea what was going to happen, and as often as not the entire day would just be spent supporting everyone else as the "idea filter" or getting called on to make detailed design decisions about subtle nuances like "how should the timing of this HUD popup look," but for the purposes of Scrum, I would fabricate a design task and some number of hours - it was not an intentionally deceptive practice, but an honest attempt to convince myself that this time, I had actually found an appropriate match between what I had written on the card and the events of the next eight hours.

Sometimes I knew in advance that I would be supporting others and could plan appropriately, but I couldn't ever plan a whole sprint like that. I'd usually get impeded two days in by a missing feature that I didn't know I needed. Even if the project wasn't totally strapped for resources, I'd be blocked on most design tasks most of the time until "full production" hit and I could really dig into how each level would work, specific enemy designs, specific tuning elements, etc.

And then once into production, it became a challenge to figure out just which things to tackle first, to "guess at the desired gameplay" when things were still unfinished, and how to avoid doing something that would just get crushed by later features. Going for weeks on end with almost no form of feedback, it was extremely difficult to make any kind of progress.

Scrum only really worked out well if I was doing clearly defined technical or asset-creation work: "Level 2 enemy placement"  is fairly reasonable and well-defined, albeit still hard to make a time estimate for, since you could take any number of passes and still have to come back to it later if a core gameplay feature gets rebalanced. "Level 2 concepting" is wide open and hard to nail into any particular process other than "copy what worked for Level 1," which still doesn't help with time estimates.

And yet at the same time, concepting has to be done on some level, or else you're just spamming some random layout down with no consideration at all to game flow or the player. The gameplay-optimal schedule essentially required a feature lockdown to come months in advance of a content lockdown so that all of these things could be worked out meticulously, and that was never possible.

Oh, and sometimes sprints would blow up mere hours in after the publisher demanded something unexpected for the next milestone. Good times. I still don't know how to deal with all of these problems. I stumbled through them and probably would stumble again. If anyone has ideas, I'd love to hear them.

Anyway, all of this thought on the nature of subjective elements in game productions led me back to Mateas, and an interesting thought: He's known for "Façade" alone, and on close reflection, that project really seemed to be driven only by the technicals of "build these really cool systems for procedural narrative, and a test case for them." Classical CS research at work, and it seemed to lead him strongly towards a view of Scrum that kept the aformentioned subjective-task problems out of the picture.

But what if I went back to the Façade concept and reconcieved it like a commercial game? That is, instead of building research-level tech to see it through, I were to depend on brutish, traditional design techniques, as if it had to be slammed out in three months to fit within some tiny shoestring budget? And what if all I did was iterate on that core concept and try to make it appealing, try to focus ONLY on subjective elements and try not to code anything remotely novel or sophisticated?

An interesting exploratory project. I might make it the thing I do next, as time and resources permit.

Related Jobs

Nuclear Division
Nuclear Division — Sherman Oaks, California, United States

Senior Game Designer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States

DevOps Engineer
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States

Client-Server Network Engineer
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States

Software Engineer - Gameplay


Christopher Braithwaite
profile image
IIRC Turn 10 used Scrum for Forza 3 with great success. I'd be interested in hearing in more detail how they implemented it for their project. I'm a big fan of Scrum, but like anything else it is a tool that must be used properly and when appropriate. I disagree with using Scrum for everything, as if one can blindly drop a project into Scrum and automagically get an on time, on budget product.

Clinton Keith
profile image

Your article does a great job of describing what a good number of game teams encounter using Scrum. Usually the problem is one or more of the following:

- The sprint goal is specified too rigidly

- The team does not have the freedom, or the understanding of the freedom or its boundaries, to explore.

- The product owner is not available to discuss immediate questions about the goal as its explored.

- The sprints simply might be too long. If you are doing 4 week sprints, try 2.

The usual solution is to have someone on the team, usually an experienced designer, become the team's product owner. The game's product owner (now the lead product owner) still prioritizes the backlog, but now the goals are a bit less rigid, and the team can plan "on the fly" a little more. This allows the team to take on more flexible goals that allow them to make more decisions about the quality and subjective fun of the goal along the way.

I see this problem as a positive sign. Teams and individuals that start to take on more responsibility for their tasks and achieving their goals will usually raise the issue that planning specific tasks, even for 4 weeks, is too speculative.

This is true, but isn't that better than having an 18 month schedule tied to a specific scope?

The fundamental principle of Scrum is to "inspect and adapt". Using Scrum, you've exposed a problem with how sprints are planned and executed (inspect), the key to being successful with it is how you alter how you work to fix that problem (adapt). It's a cycle that never ends.

Good luck!


Justin Nearing
profile image
Thanks for the comment, Clint, I'll have to remember those points for my own team. The thing I like most about Scrum is that its supposed to be adaptable. Each team is different, with different problems and risks, and its important to be able to explore new processes to fix those problems on the fly.

Glenn Storm
profile image
Thanks for another great read, James. I appreciate you continuing to bear this process for the Gamasutra community. Also, I appreciate Clinton's comments in relation to the issues you raise. In fact, Clinton's earlier ideas immediately sprang to mind as soon as the problems were suggested in this article.

James, it seems to me you've zeroed in on the perceived shortcomings of SCRUM in relation to game development, as Clinton said. This is neatly illustrating how SCRUM seems work as an excellent organizational tool for development on clearly defined (technical) tasks, but how it inevitably falls apart if you have to develop "fun" or mitigate "frustration"; two very common, very subjective game design tasks that will be in opposition to the constraints the SCRUM is designed to provide. That is, unless the process itself begins to adapt, as Clinton mentions.

I immediately thought of Clinton's article, "Beyond Scrum: Lean and Kanban for Game Developers". [
kanban_for_.php] Which, also describes these shortcomings, but then goes on to illustrate a more flexible organizational tool derived from a hybrid of practices. I guess I wasn't commenting in those days, Clinton, but really it's a fantastic article that's been a part of my organizational thinking and practice ever since.

I would agree, almost without exception, that the clear cut nature of sprints work great when the questions to be answered; when the problems to be solved, are definitive and measurable. That, as opposed to, when developing any subjective unknown, such as a novel control scheme, art styles, sound effect design or the like; that simply defies a schedule and the constraints of a sprint. I can make no claim that development I've been involved in has followed a formal SCRUM process, but the writing is on the wall, written in blood, sweat and tears.

Another way to tackle this problem is to begin to make the subjective not so subjective. To begin to understand the subjective issues that commonly frustrate game design for the purposes of developing better best practices. I am in favor of this tactic and have been pursuing that angle formally.

Good luck, James! Keep going!