Chapter 5. User Stories

Communication is one of the biggest challenges for developing games, and one of the largest communication problems is language. Stakeholders often speak the language of business. To them, cost and consumer value influence how they see the world and communicate.

Developers speak a different language. Their language pivots around their specialty. Programmers speak the language of math, code, and algorithms. Designers speak the language of pacing and reward. Artists speak the language of polygon color, texture, and lighting. These languages are not exclusive of one another, but they present communication challenges when everyone on the team needs to understand the same vision of the game.

The solution is for developers to speak the language of the stakeholders. We can’t expect stakeholders to learn the language of development (although many stakeholders are often familiar with the jargon). As a business, the language of the customer must be the universal language of development. To this end, we need to be sure that the critical lines of communication between the stakeholders and developers—and even between developers of separate disciplines—are made and kept open using this universal language.

This is where user stories come in. A user story is a short description of a game, tool, or pipeline feature that has a clear value to a user. If the feature is a tool or pipeline change, the user can be a developer who uses the tool or pipeline to make the game.

Up to this point, we’ve used the terms feature, requirement, and PBI to define what is developed. This chapter introduces user stories as a replacement for all those terms and describes how good user stories are created.

A Fateful Meeting

I recall a certain meeting years ago on a game project called Smuggler’s Run. Although I’ve attended hundreds of meetings like it, none other would change the focus and course of my career as this one did.

The purpose of the meeting was to review the work remaining to achieve the alpha milestone, which was two weeks away. Alpha was the cutoff date for incomplete features; features planned for but not fully implemented were to be cut from the game. You could sense how close alpha was. Smuggler’s Run needed to be out for Christmas. It was also a launch title for the PlayStation 2. Everything rested on this game being on time. No one really wanted to be at this meeting; there was much to do, but the meeting was critical and, as the director of product development for the studio, I had to know whether we would achieve alpha.

All the leads attended. I had to keep an eye on the lead programmer and lead designer; they often clashed over the ideals of design and the feasibility of what our technology could accomplish. They approached their roles perfectly, and the natural tension between them benefitted the game. I just had to make sure it didn’t go too far.

That day tested that tension. The lead designer had brought a big concern to the meeting. “When are the animals going to be added to the game?” he asked. The lead programmer didn’t have a clue about this feature. So, the lead designer pulled out the game design document and pointed to a paragraph on page 97, which described the feature. The game was to have animals wandering about the levels in herds that avoided the player vehicles. The feature had been added to the game design document partway through the project, and the lead programmer had not read it.

The lead programmer didn’t know whether to laugh or explode in anger. “How am I expected to know when a new paragraph was added to the design document?” he demanded. “I barely read it the first time!”

We spent some time calming everyone down and were finally able to discuss options for the feature. In the end, a simplified version of the feature was added. Rather than herds of animals avoiding the vehicles, lone animals wandered about ignoring the vehicles and, when hit, turned into tumbling rag dolls. As it turned out, this was a popular feature in the game. Players spent hours hunting down the entire populations of animals. Had this feature been more exploited, the game would have met with even more commercial success.¹

¹ And the ire of animal rights groups everywhere

As the project director, that meeting was a wake-up call about the issues of documentation and communication. I saw the futility of trying to know everything about a game up front and using monolithic documents to capture change and knowledge. This started my path to agile.

The Smuggler’s Run game design document was well maintained by the designers, but it still failed in a few basic ways:

• It failed to communicate the priority of features: Each team member evaluated the priority of each feature on their own.

• It failed to communicate changes to the rest of the team: Few team members reread the document on a regular basis to keep up with the frequent changes.

The conversation that occurred two weeks before alpha was very fortuitous, but requirements that make it into the game shouldn’t be left to chance. What we had was a failure to communicate. The information in the document was valuable, but the document itself was a poor medium for communicating change and priority.

This underscores some problems with traditional requirements gathering and tracking. What we need is a method that does the following:

• Communicates the priority and value of the features: The team needs to focus on delivering the highest-value features ahead of the lower-value ones.

• Enables change and communication of change: Change is going to occur, and discussions about those changes need to happen regularly and frequently.

• Is a placeholder for future communication: Documentation can’t replace conversation.

• Enables details to emerge as more information is learned: It shouldn’t require all design details up front or impose a great deal of effort to spread knowledge or change.

• Enables continuing refinement of the work estimated for each feature as the team learns more: Uncertain features can’t have precise estimates. Accuracy can grow as the feature requirements are refined.

User stories were designed to address these needs. The rest of this chapter defines what they are and how they are used.

What Are User Stories?

User stories were created (Beck 2000) to express the value of features to a customer and elicit conversation. Identifying the value of individual features coupled with the benefit of agile development demonstrating value throughout a project is a powerful combination. User stories represent the requirements of the game from the point of view of the user, not the developer. They don’t fully describe design details. Stories are placeholders for conversation about the details. User stories follow a template determined together by the team and stakeholders. Mike Cohn (2004) recommends the following:

As a <user role>, I want <goal> [so that <reason>].

This template includes the following:

• User role: A customer of the game or a user of the pipeline who benefits from this story.

• Goal: The goal of the story. This is a feature or function in the game, tool, or pipeline.

• Reason: The benefit to the customer or user when this feature or function is used.

The last portion of the story template, “so that <reason>,” is optional. It’s often left out when the reason is apparent.

Examples of user stories follow:

As a player, I want a player mute button so that I stop being distracted by some of the other players online.

As an animator, I want to change animations directly in the game without restarting it so that I can iterate faster on animations.

As a prop modeler, I want the exporter to check the naming conventions of the props to ensure that they are correct so a poorly named prop does not crash the game.

As a player, I want to see my health level.²

² It’s apparent why I want to see my health level, so we don’t need to state the reason.

Levels of Detail

Teams complete one or more user stories per sprint. These user stories have to be small enough to fit into a sprint. Had we used stories on Smuggler’s Run, we may have had an initial story something like the following:

As a player, I want to see herds of animals running around the environment so that it seems more realistic and alive.

As it increased in priority and approached implementation, it could have been disaggregated into smaller stories such as the following:

As an animal in the game, I want to run away from vehicles.

We don’t want to break down every large feature into sprint-sized stories at the start of the project. That creates too many stories to be practically managed by the product owner. Instead, priority determines when features are broken down. Higher-priority stories are worked on sooner, so they are broken down into smaller stories in a planning meeting. User stories that are too large to be accomplished in a single sprint are called epics, such as the animal herd story. Sometimes a number of related user stories are gathered together in a theme. Themes are beneficial for aggregating user stories together for estimating.

User stories, epics, and themes can be decomposed into smaller user stories. Figure 5.1 shows an example of an online epic broken down into smaller stories.

Figure 5.1. Breaking down an epic into smaller stories

In this example, the stakeholders identify the lobby and online game as two online epics. They break down the gameplay story further into death-match stories. This decomposition of stories occurs throughout the project. A product backlog can be considered as a hierarchy of user stories that change. Branches grow in detail or are pruned as we learn more about what is fun.

Conditions of Satisfaction

Sometimes we want to add some specific details to a small story.

Take the following example story:

As a player, I want to shoot an enemy character and see it react so that I know when it is hit.

If this leaves a bit of uncertainty in the details, the stakeholders and team decompose the story into smaller stories, as shown in Figure 5.2, to add those details.

Figure 5.2. Disaggregating a story to add details

However, if the initial story is small enough to fit in a sprint, then this decomposition is not necessary. Another approach is to list these substories as conditions of satisfaction (CoS), as shown in Figure 5.3.

Figure 5.3. Adding details as conditions of satisfaction

This is a very powerful tool. CoS help the team understand the ultimate goal for every user story and avoid delivering the wrong feature at the sprint review.

CoS have to be testable. The team should verify whether the CoS are met by running the game and ensuring that behaviors described exist.

Using Index Cards for User Stories

As with tasks, user stories are often represented in the form of a 3-by-5 index card. These cards are a great medium for handling user stories for a number of reasons:

• The size of the card constrains the amount of detail in a story. We don’t want stories to be large documents that include every necessary design detail. A small card prevents this from happening.

• Cards can be physically manipulated (sorted, edited, replaced, and passed) by many hands in collaborative settings (daily scrums and planning meetings).

• The backside of the card is an ideal location and size for listing CoS. Once again, the constraint imposed by the size of the card prevents pages of CoS from being listed, which interferes with the story being negotiable.

INVEST in User Stories

What makes a good story? Mike Cohn and Bill Wake (2003) suggested the acronym INVEST, which stands for the following attributes of a good story:

• Independent

• Negotiable

• Valuable

• Estimatable

• Sized appropriately

• Testable

Independent

Stories should be independent from other stories in the order they are implemented. Dependencies create problems that make them hard to prioritize and estimate. For example, suppose we have the following two stories:

As a player, when I shoot a door, it splinters into hundreds of pieces of wood.

As a player, when I shoot a window, it shatters into hundreds of shards of glass.

If the technology for creating this effect does not exist, then the first of these stories to be implemented requires underlying technology to be developed as well. Because these stories appear almost identical, they should not have such a discrepancy of work to implement. The dependency inherent in the first story implemented does not make this possible. There are two solutions to this. The first is to combine these into one larger story:

As a player, I want to shoot certain objects and have them break into many pieces.

The door and windows could be handled as two conditions of satisfaction. This works when the larger story fits within a sprint. If the aggregated story takes longer, we break the story into the one that creates the base technology:

As a designer, I want to shoot certain objects and have them break into many pieces.

and into two others, which allow the window and door instances of this effect:

As a player, when I shoot a door, it splinters into hundreds of pieces of wood.

As a player, when I shoot a window, it shatters into hundreds of shards of glass.

These stories aren’t truly independent because the first story must be completed before the others, but dependency is now clear, where it wasn’t in the first place.

Negotiable

Stories are not contracts or detailed requirements. They are placeholders for conversation between the stakeholders and the team. A story that is too detailed and specific shortcuts those conversations by creating the illusion that all details are known and don’t require any dialogue. For example, consider the story in Figure 5.4.

Figure 5.4. A story that doesn’t allow much negotiation

The detail in the story may not be as comprehensive as it implies. Did the customer forget about sound effects of the tires on these surfaces? Do they want more effects in the future? Would they like wheel friction to change depending on the surface? Figure 5.5 shows a better version of this story.

Figure 5.5. A more negotiable story

This story is a better placeholder for the conversation. It drives conversation. The requirements of the water spray and grass particles could be added as conditions of satisfaction on the backside of the card if the stakeholders want to ensure that these things are demonstrated.

Valuable

Stories need to communicate value not only to the player but also to the team developing and marketing the game. The product owner adjusts the priority of user stories on the product backlog by judging their value. Stories not expressed in terms of value are difficult to prioritize. Consider the following story:

Sort rigid bodies in the environment into islands of objects local to one another.

This story does not communicate value to the player or pipeline users, but it may be a story that has a great deal of value. In this example, a physics programmer may request that these changes be made so that the game runs at 30 frames per second (fps). If this is the case, the story can be written to express this value to the player:

Sort rigid bodies in the environment into islands of objects local to one another so that we maintain 30 fps.

Note that the expression of the user role is missing in this story. The player and the developers all benefit from the game running at 30 fps, which is far more enjoyable than a game running at half that rate.

Estimatable

Stories need to be estimated. This requires knowledge about what we are building and how we are going to build it. If not enough is known or the scope of the story is too large, then we cannot estimate it well enough.

Sometimes stories push the boundaries of knowledge about what our technology can do or the level of effort required. For example, suppose the following story was introduced:

As a player, I want to knock over stacks of boxes to block the AI players from approaching me and to allow me to escape tight situations.

This story could present a number of problems to the programmers:

• The physics engine might not support a stable stacking of objects.

• The AI navigation system may not “see” dynamic objects such as boxes in the environment.

Implementing this story may be simple or require months of effort. To mitigate this risk, a story is introduced to explore these risks. This story is time-boxed, or limited in the amount of effort spent on investigating these risks; we don’t want to sign a blank check. This type of story is called a spike, and its purpose is to add knowledge about the cost of implementing the main story. After the spike, the product owner and the team should better understand the cost of implementing the full feature.

Sized Appropriately

Stories need to eventually be made small enough to fit into a sprint when implemented. If they are too large, they are disaggregated.

A group of small stories can be combined into a larger story more easily managed as a theme. Examples of this are minor bug fixes and polishing tasks placed on the product backlog. We don’t need to track and estimate small one-hour fixes within separate stories.

Testable

The story should be written so that it is verified before the end of the sprint. Without this, the team cannot determine whether they satisfied the stakeholders. It’s best to use the conditions of satisfaction on the back of the card to define those tests. Some stories require approval to check off.

Consider the following stories:

The prototype shooting level is fun.

The boss character model is complete.

Both of these stories are subject to interpretation. In this case, the team had a lead designer or lead artist to sign off on the level or model, respectively. The CoS should identify when these approvals are needed. Sometimes a team adds a column on the task board between the “in progress” and “done” columns called “needs verification.” This is a holding stage for all the stories that are considered complete only when a lead signs off on them. If a team has many subjective stories or tasks, this is a good solution.

User Roles

Many games provide difficulty levels for the players who buy the game. They usually implement several levels of difficulty as a means of adding replayability and accommodating a range of player skills. The levels are differentiated by scaling challenges in the game such as the number of opponents and damage from weapons hits.

Games benefit from considering a broader range of players and placing more emphasis on their roles. As an example, consider the popular Battlefield games, which enable players to adopt specific roles. If you are not familiar with the games or the specialties, they are divided across these roles:

• Assault specialist: Is equipped with an assault weapon and grenades for close quarter combat

• Sniper: Carries a high-power sniper rifle and a targeting device used to call in precision strikes

• Engineer: Has a bazooka and mines and can repair vehicles

• Special forces: Carries a light automatic weapon and C4 explosives for sneaking around behind enemy lines disrupting opponents

• Support: Totes a heavy automatic weapon and a radio to call in mortar strikes

These specialties require different behavior from the player. It’s difficult to insert these roles at the end of a project. They need to be developed in parallel during pre-production because they have an impact on level design and should be added before production starts.

User stories allow roles and their associated features to be clearly defined. A good method for differentiating roles is to use them in the story template. Instead of saying this:

As a player, I want a bazooka so I can blow up tanks.

the story becomes this:

As an engineer, I want a bazooka so I can blow up tanks.

What’s the difference? It’s mainly one of value and priority. For a generic player, the bazooka is one of a host of important weapons. However, for the engineer, the bazooka is probably the most valuable weapon because the engineer role exists to counteract tanks. There’s nothing more gratifying than taking out a tank with a well-placed shot. The bazooka is useless for a sniper to carry because snipers maintain a distance from the fight that is greater than the bazooka’s range and firing it leaves a trail of smoke that reveals the sniper’s position.

Even if your game isn’t going to use such specialties, there is a lot of value in brainstorming the various types of players early in development. Who is buying your game? Do you hope to attract casual and hardcore players to your game? If you do, it benefits you to identify the “casual player” role in some of your stories. It may lead to many small decisions such as offering an option to simplify the controls or adding more checkpoints so the casual gamer doesn’t become frustrated.

User roles also apply to developers who use the pipeline and tools to make the game. Pipeline and tool stories have to express value as well as gameplay stories. This enables the product owner to better prioritize the order in which these stories are implemented. For example, if animation creation is a bottleneck for a project, the product owner elevates the priority of stories that address the animation pipeline. This is best accomplished by having those stories start with the phrase “As an animator....” Here’s an example:

As an animator, I want the animation exporter optimized so I can create and test more animations.

Defining Done

The team commits to completing a number of stories from the product backlog and demonstrates that these are done in the sprint review. However, defining what done means can be challenging. If the team assumes a feature only needs stand-in assets and the stakeholders think they’ll see shippable-quality assets, the stakeholders will not be happy with the results. An agreement of what done means has to occur before each story is broken down into tasks.

There are standard and additional definitions of done. The standard definition of done applies to every story. For example, done might mean that every feature implemented runs on a development PC without any crash bugs. The following list is a collection of standard definitions of done that teams might adopt:

• The game runs on a development machine.

• The game runs on one or all target platforms.

• The game runs at a shippable or target frame rate.

• The assets all conform to naming and budget conventions.

• The game runs within the memory budget and has no memory leaks.

Teams expand the standard definition of done by improving their practices. This enables the team to continually improve their effectiveness. Each additional element in our definitions of done reduced debt carried forward. Debt represents work that must be done in the future before we ship a feature. Debt, or undone work, also represents risk. We don’t want to discover shortly before we ship a game that a key feature causes the frame rate on the PlayStation 3 to drop to 10 fps; we may have built hundreds of assets based on the assumption that 30 fps is possible. The sooner we address debt, the less it costs to address it. Increasingly stringent definitions of done prevent debt.

Additional definitions of done are created for specific stories and defined in the CoS:

As a designer, I want to have my character jump across a gap to determine whether the mechanic is fun.

CoS: Poses will be used in place of any animation.

Collecting Stories

Collecting stories in the product backlog is an ongoing process that occurs throughout development. At the start of an agile project, the team and stakeholders collect enough stories to encompass all the major requirements (epics) known and enough detailed stories to enable the team to start iterating.

The collection of stories for an agile project isn’t the sole responsibility of a few leads. Instead, there are many ways to gather stories including marketing studies and focus group questionnaires, but the most beneficial method for game developers is the story-gathering workshop.

The story-gathering workshop brings stakeholders and teams together to brainstorm user stories for the game. The product owner facilitates the workshop and invites everyone who can contribute ideas.

Attendees discuss the goals and constraints for the game. This is especially important if it’s the first workshop. For example, if the title is to be tied to a license, then the customer who represents the licensor describes what is allowed in the game, such as not allowing a licensed car to catch fire. The publisher shares the major goals of the game including the product’s position in their portfolio, release date options, and targeted demographics. User roles are explored. Domain experts discuss risks and opportunities. For example, the design leadership may identify areas of strength and weaknesses in the level design feature set related to delivering on requested mechanics.

At the first workshop, the major epics are identified. An example of an initial summary of epics for a first-person shooter might resemble Figure 5.6.

Figure 5.6. Identifying a hierarchy of epics is valuable in communicating the big picture.

The story-gathering workshop identifies enough detailed stories to fill the next release. This requires the product owner to identify story priorities and discuss the capacity and capabilities with the teams. For our first-person shooter project, the product owner identifies that the player control and artificial intelligence epics are the most valuable areas to focus on for the next three or so months. If the teams confirm that they have the necessary specialists to accomplish work in these areas, then the workshop focuses on breaking out stories sized appropriately. As the workshop drills down on smaller epics, then the subtrees become populated with stories that fit into sprints. Figure 5.7 shows some of the smaller epics identified for player control.

Figure 5.7. Smaller epics

The team and domain experts are critical in contributing their ideas here. If, for example, the physics engine causes problems with player controller development, they should discuss it in this meeting. This may lead to work that investigates the potential issues with physics.

Advantages of User Stories

User stories have many advantages over the traditional practice of written requirements. This section emphasizes the face-to-face communication advantages and ease of comprehension.

Face-to-Face Communication

At the start of this chapter I told the story about a misunderstood feature in Smuggler’s Run. This misunderstanding was driven mainly by a lack of ongoing communication between the designers and the rest of the team. User stories encourage an ongoing face-to-face conversation between separate disciplines that must happen for game development teams to be effective.

Consider the following requirement:

As a player driving a vehicle, I want a rearview mirror to see behind my vehicle.

On the surface, this requirement seems clear. However, there may be a number of issues with delivering this function to the player:

• Do we show a mirror in the third-person camera view? Wouldn’t a mirror floating above the vehicle look a little odd?

• If the AI opponents cheat by using “rubber banding” or other tricks to catch up with the player, wouldn’t the mirror reveal these tricks?

• Does the second view of the environment reduce the overall rendering budget?

Many of us have seen issues like these crop up during implementation that impact the schedule by adding work not foreseen at the start of the project. By having these conversations at the start of every sprint, we create opportunities to address such issues when we know far more about the immediate value they provide.

Everyone Can Understand User Stories

Mike Cohn writes, “Because stories are terse and are always written to show customer or user value, they are always readily comprehensible by business-people and developers.”³ Consider an actual story I’ve seen:

³ Cohn, M. 2004. User Stories Applied: For Agile Software Development. Boston: Addison-Wesley. Reproduced by permission of Pearson Education, Inc.

As a programmer, I want a checkbox in the audio objects menu to control the bLooping boolean flag.

Although this story follows the template, it fails to communicate value. It’s a task, not a story. Does the programmer benefit from this change? Perhaps they don’t have to write separate looping audio object code, but that is not communicated here. More than likely, the audio designers wanted looping sounds in the game. If this is the case, the story should be written as follows:

As an audio designer, I want to set a looping flag on a sound object so that I control looping environmental sounds in the game.

This story represents real value that the product owner understands. Alternatively, we could have expressed the story in terms of the player. The average player does not understand looping sounds but certainly would miss the depth of the sound environment if the designers didn’t include the capability to loop sounds in the background such as a babbling brook or the sounds of combat off in the distance.

Summary

This chapter has covered the creation of stories and explained how they clearly communicate intent between the stakeholders and developers. Stories encompass what have been called features, PBIs, and requirements. Now that we have this powerful tool, we’ll examine how to use it for planning over the longer term.

Additional Reading

Cohn, Mike. 2004. User Stories Applied. Boston, MA: Addison-Wesley.