This week I wanted to focus on agile documentation. The way I originally learned to design a game was to write a comprehensive document before beginning development. In my previous article, I mentioned that detailed documentation compiled at the beginning of a project was deceptive – it leads us to believe that we know more about the game that we’re developing than we actually do. However, this doesn’t mean that the game should have no documentation, it simply changes how this documentation is written and communicated to the team. The way agile handles design documentation can be separated into macro-design and micro-design.

The macro-design

The macro-design is the big picture stuff. This is the stuff that we can figure out early in the project.

The pitch

All game projects with more than one developer on them have some sort of pitch, even if it isn’t a formal pitch deck or video. At some point, you have to persuade other people that the concept that you want to develop into a game is a concept worth developing. Maybe the person you need to persuade is a publisher who might fund development, or maybe the person you need to persuade is another developer you want to join your team.

You should be able to condense the important information about the game you’d like to develop into a 3 sentence pitch that takes approximately 30 seconds to talk about. If you can’t get your audience interested in the game in the first 30 seconds of your pitch then you have probably lost your audience. There is a lot of great advice on how to pitch your game already out there. I recommend checking the GDC Vault for some of the talks on pitching.

I’d like to share one of my favorite pitches from Double Fine’s Amnesia Fortnight. I recommend reviewing all of their pitches to see what they all have in common, but Dear Leader is probably my favorite of the pitches. In 30 seconds, Anna Kipnis is able to communicate the concept of the game, the visual style, the audio style, and influences from other media. This is a lot of information communicated in a very short period of time.

The vision

The vision statement or vision document is going to be significantly longer than three sentences. It’s probably going to be about five pages long and is again going to be at a very high level. It should cover your key goals for the project, what makes your project unique, who your customer is, and why they would want to buy your game. I’d like to share an abridged version of the Fallout vision document (you can read the full document here):

I’ve left a few of the bullet points from the document out, but it’s surprising how much of this vision statement applies not only to the turn based strategy game that the first Fallout was but also to the first person shooters that Fallout 3 and 4 are.

The micro-design

The micro-design is where we dive into the details. We won’t know these details at the start of the project but we will figure them out as we go along.

The sprint goal

Every sprint, we hold a sprint prioritization and a sprint planning meeting. At these meetings, one of the tasks we accomplish is committing to a sprint goal. This is less a piece of documentation than it is a conversation between the developers, ScrumMaster, and product owner. The sprint goal tells us which features and user stories we will be working on this sprint, and which ones we will not be working on because they don’t support the sprint goal.

The features & user stories

Writing features and user stories is where the written micro-design takes place, but even these are created as part of a conversation. Features and user stories should communicate the intent behind the feature so that developers don’t hit a road block if things don’t go according to plan.

Features are high level parts of your game that describe new capabilities the customer will have when the feature is complete. These should be minimally described because they will be refined over time.

At the sprint planning meeting, the team will break down features to approximately 2 sprints worth of user stories. A well written user story has no dependencies, is written to be negotiable, communicates the value of the user story, is able to be assigned a reasonable time estimate by the team, is small enough to fit into one sprint, and has conditions for satisfaction that can be tested to verify that the user story has been completed. As a rule of thumb, any user story bigger than 16 hours should be broken down into smaller pieces.

I hope this helps you understand how documentation changes in an agile project. Let me know if you have any questions in the comments below.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-Wesley.