Chapter 8
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 player must be the universal language of game 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 and PBI to define what is developed. This chapter introduces user stories as a replacement for those terms and describes how good user stories are created.
Speaking Different Languages
Many years ago, our studio was working on a Resident Evil port for the Nintendo 64. It was a very challenging project to port a CD game filled with video cinematics onto a much smaller cartridge, but the biggest challenge was communicating with the Japanese stakeholders from Capcom.
First, it was very important to them that player control be responsive. When someone moved the controller, they wanted the character on the screen to reach the next frame. Somehow that wasn’t clear to us, and we kept adding embellishments, such as animation blending, which slowed the responsiveness down slightly. After months of wasted effort, we found ourselves being screamed at in Japanese by a Capcom producer while his poor translator tried to keep up.
The second, and worst, blunder in communication was with the alpha version of the game. As a Christmas title, it was important for us to hit that date and we thought we had. Unfortunately, our definition of alpha, where all the features were in the game, but not fully debugged and optimized, was not the same as theirs, which they defined as fully debugged and optimized. Apparently, both definitions were in different documents, and they were never reconciled beforehand. As a result, we missed the Christmas launch and were yelled at in Japanese again.
The Solutions in This Chapter
This chapter addresses the traditional issues of communication in video game development and introduces user stories as a solution. While not a complete replacement for all documentation, user stories provide the following solutions:
They communicate business value that allows better communication between stakeholders and developers.
They promote continual conversation among all groups, which is better than a pure documentation approach.
They are hierarchical, allowing a breakdown of detail for the work that is immediate and needs refinement of understanding.
They allow for testability through specific criteria.
What Are User Stories?
User stories were created to express the value of features to a customer, set quality expectations, and elicit conversation (Beck, 2000). 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 mute player 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.1
1. 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 (Chapter 7), 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 split 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.
Note
Some projects have required an even higher level of scope than an epic and have introduced what they call the saga!
User stories, epics, and themes can be decomposed into smaller user stories. Figure 8.1 shows an example of an online epic broken down into smaller stories.
Figure 8.1 Splitting an epic into smaller stories
In this example, the stakeholders identify the lobby and online game as two online epics. They split 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. This chapter defines how to split stories in more detail later.
Acceptance Criteria
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 8.2, to add those details.
Figure 8.2 Splitting 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 acceptance criteria (AC), as shown in Figure 8.3.
Figure 8.3 Adding details as acceptance criteria
This is a very powerful tool. AC help the team understand the ultimate goal for every user story and avoid delivering the wrong feature at the Sprint review.
AC have to be testable. The team should verify whether the AC are met by running the game and ensuring that the behaviors described exist.
Experience
“I really thought user stories worked well in the development of our game. It forced the designers to really think out what they wanted. On my last project, programmers worked closely with the designers on the acceptance criteria so that everyone knew what was expected. It was critical that the programmers found out as much detail as possible. It kept any creeping seat-of-the-pants design to the planning session where all the interested parties were present. Programmers debated the merits of some of the design decisions, and designers came to understand the technical effort involved. Programmers with design skills had an opportunity to get their input heard.”
—Mike Riccio, Lead Programmer, High Moon Studios
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 AC. Once again, the constraint imposed by the size of the card prevents pages of AC from being listed, which interferes with the story being negotiable.
Experience
Constraint is really hard, even when limited to an index card. At first, we stuffed lots of written detail on our cards by printing them with tiny fonts or stapling ten-page documents to them. Our coach eventually limited us to using only permanent markers.
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
Estimable
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 acceptance criteria. 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.
Note
One key difference to note is that the customer for the first story is the designer who uses the system to finish the second story. This enables the team implementing the first story to focus on the needs of the designer, including an interface to tune the system, which the player does not need. Beware of the “parts on the garage floor” problem described in Chapter 14, “Agile Design.”
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 8.4.
Figure 8.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 8.5 shows a better version of this story.
Figure 8.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 acceptance criteria on the backside of the card if the stakeholders want to ensure that these things are demonstrated.
Note
A missing requirement in an overly detailed story is more likely to lead to that requirement being overlooked by a team focused on fulfilling the “letter of the law.” Negotiable stories serve the “spirit of the law” better.
Harness the Creativity of Teams!
Negotiable stories raise questions on purpose. They enable anyone on the team to suggest ideas. Talk about being motivated when millions of people love a feature that you thought up!
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.
Estimable
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 timeboxed, 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.
Spikes and Tracer Bullets
Spikes are important for video game development. Spikes are timeboxed stories. The reason for this importance is that spikes address areas of great uncertainty, and their only goal is to create knowledge that helps the Product Owner evaluate the cost of other stories. For example, the Product Owner may have a spike defined that says the following:
As a Product Owner, I want to see a mock-up video of how our fighting mechanic might look on an iPhone.
The Product Owner may only be willing to spend a Sprint or less of the team’s time investigating something. In this case, he wants to know what a mechanic might look like on the iPhone before developing the iPhone technology. At the end of the Sprint, the team shares what it has learned so far. If the Product Owner decides to investigate further, he can create another spike.
A variation of a spike are tracer bullets. In warfare, tracer bullets are special bullets that glow when they are fired from a machine gun. There is usually one tracer bullet for every 10 or 20 normal bullets. These tracer bullets allow the gunner to see where the other bullets are headed. For game development, a tracer bullet is a spike that is used to measure the cost or quality of a small piece of work that will help us estimate the larger set. An example of a tracer bullet would be to create a shippable section of a level that will help the team understand the cost of all the levels anticipated for the game.
Sized Appropriately
Stories need to eventually be made small enough to fit into a Sprint when implemented. If they are too large, they are split up.
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.
Tip
One trick teams do is to collect all their small polishing tasks into a single spike each Sprint and dedicate a fixed and predictable amount of time polishing the game. Over time these tasks are included at the start of the Sprint, and the spike becomes unnecessary.
Testable
The story should be written so that it is verified before the end of the Sprint. Without this, the team cannot determine whether it satisfied the stakeholders. Using the acceptance criteria on the back of the card to define those tests is best. 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 AC 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.
The Impossible Story
One time I was handed a user story that read “As a player, I want the camera view to shift to the side a half-second before I hit the jump button, so I can see a cinematic view of my jump.” To this day, I have no idea how anyone could implement that feature!
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. Inserting these roles at the end of a project is difficult. 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 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 order the stories to be implemented. For example, if animation creation is a bottleneck for a project, the Product Owner raises the order 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.
When to Avoid User Stories
User stories are fine to a certain point, but they don’t have to be used everywhere. Stories used to address bug fixes or asset changes are pointless. Do we really need to define which user doesn’t want the game to crash?
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.
Note
Many of these points do not directly lead to the creation of stories right away but are placed in a “parking lot” of topics to be discussed in detail as time permits.
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 8.6.
Figure 8.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 8.7 shows some of the smaller epics identified for player control.
Figure 8.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.
Planning a Hand-to-Hand Combat System
I’ve worked on two projects that have included hand-to-hand combat. The first game was a sequel to a popular fighting game developed by another studio. The hardship the original project suffered—it took more than four grueling years to develop—was due to the complexity of its hand-to-hand combat system.
The challenge of hand-to-hand combat systems is to create a proper blend of responsive player control and smooth, seamless animation. The approach chosen for the original game was entirely physics-based. Animations drove the motion until a collision occurred. The force of a collision then controlled the motion of the character. It was an ambitious system that promised flexibility and a great degree of player control. Unfortunately, it didn’t allow for a very good-looking character movement. Much of the contact between characters was resolved incorrectly. After wasting enormous amounts of effort trying to make this system work, the team reworked the system, eventually settling with an entirely animation-driven solution. The publisher wanted the sequel to implement the physical solution, but after several months of experiments, we could offer no good solution, and the project was abandoned.
Based on this previous experience, I had some opinions about the technical approach when I attended the story workshop for another game with a hand-to-hand combat system. The Product Owner introduced the feature and told us that the most important value of this feature was that it be fun and look good.
The discussion eventually touched on a physics-driven solution. Given my experiences from the past project, I was able to give a detailed description of the problems this created. When the animators, programmers, and Product Owner heard this, they decided that the risk and cost potential did not justify the physics approach, and attention turned to an animation-driven solution.
This small example demonstrates how story workshops address the vision of each feature and the potential design impacts with a cross-discipline group. Too often, projects don’t discuss this impact, which leads to decisions that take the project down a bad path.
Splitting Stories
Splitting epics into smaller stories is a bit of an art form. Teams new to Agile tend to split stories into requirements or development tasks, or simply split stories too soon.
Every time you split a larger story into smaller ones, you are making design decisions. We want such design decisions to be made “just in time,” or “as late as we can responsibly make them” simply because the longer we wait, the more we will learn and our decisions will be better.
Splitting Too Far
The most frightening Product Backlog I’ve seen was at a client working on a large MMO. I was asked to see their “Product Backlog Room,” which I had never heard of before. They brought me to a large windowless room whose walls were completely covered with more than 1,000 highly detailed index cards. I immediately felt like Shelly Duvall’s character in The Shining, when she encountered her husband’s draft novel only to experience the horror of the detail of what he was writing. I quickly exited the room, and we had a conversation about the dangers of splitting stories too soon. One thousand story cards on a wall are just as bad, if not worse than, a huge design document!
This section lists some useful strategies and tips for splitting stories.
Split Along Research or Prototype Dependencies
Doing some exploration before you can decide how to split an epic further is often necessary. Start with splitting out a research or prototype story first.
Example epic: As a player, I want to react to impacts.
Example split:
As a designer, I want to know where an impact occurs.
As a player, I want to react based on the impact location.
Reasoning: The first story allows some research on collision physics and helps the team and designer experiment with different strategies. (For example, would a simple strategy of having high, middle, and low collision volumes be good enough, or do we need something more complex?)
Example epic: As a player, I want to buy weapons using my PayPal or my credit card accounts.
Example split:
As the Monetization Product Manager, I need a system for processing and recording payments in a secure way.
Acceptance criteria: A player can buy a weapon with PayPal.
As a player I can buy weapons with a credit card.
Reasoning: An infrastructure or architecture often needs to be in place, which requires a dependent story to be implemented first.
Split Along Conjunctions
If your epic has a conjunction (for example, and, if, but), you can often split out stories from either side.
Example: As a player, I want to smash wooden crates and doors open.
Example split:
As a player, I want to smash wooden crates open.
As a player, I want to smash wooden doors open.
Reasoning: Do the simplest or most important first. Also, note that the first of anything is usually more expensive, so this makes it easier to see costs by sizing these stories individually.
Split by Progression or Value
Sometimes we split an epic into stages of progression, ordered by their value to the player.
Example: As a player, I want to be coached on the rules of poker and ways I can improve my home game.
Example split:
As a player, I want the game to have some first-time user experience (FTUE) tips for playing poker.
As a player, I want the game to give me tips for improving my home game.
As a player, I want the game to evaluate my hand strength and suggest the next move.
Reasoning: This split details some of the ways players can improve with a progression of stories that are a bit more specific, from players first encountering the game to later in the game as they become better.
Other Splitting Tips
The following are some other splitting methods to try:
Split by acceptance criteria. Acceptance criteria often make perfect stories themselves.
Split by discipline capacity. For example, if you don’t have enough animation support, then you might have to split off an “Add polished animations to..…” story for the next Sprint (after you’ve done everything else to avoid this).
Make sure your split stories still meet the INVEST criteria and are not at the task level.
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 beginning of Chapter 7, “The Product Backlog,” 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 businesspeople and developers.”2 Consider an actual story I’ve seen:
2. 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 Looping 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.
What Happens to the Design Documents?
User stories collected on a Product Backlog are meant to replace much of the design documentation. However, external stakeholders, such as publishers, may demand to see design document in a traditional format, and many tools that manage Product Backlogs will output the Backlog in a single document.
Personally, I would still maintain a technical design document that listed technical risks and strategies for handling those risks, but I would use that document to help order the Product Backlog, which is where all work done by the team originates.
What Good Looks Like
User stories aren’t the only form of written documentation on teams. As mentioned earlier, they are placeholders, primarily for conversation, but also for other forms of communication:
Licensed games, which will have extensive documentation that describes specific requirements for a property
Storyboards and other art
Reference art
Teams will explore the dividing line between what needs to be written down and what needs to be explored and communicated frequently. The bottom line is that you can’t document away uncertainty.
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.