Reference: Clinton Keith, Agile Game Development with Scrum, Chapter 5.
Flappy Bird gameplay video.
User stories describe the requirements for the project. Ideally, we need a method to track and communicate the requirements that
- Communicates the priority and value of the features;
- Enables change and communication of change;
- Is a placeholder for future communication;
- Enables details to emerge as more information is learned;
- Enables continuing refinement of the work estimated for each feature as the team learns more.
User stories express the value of features to a customer and elicit conversation. 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.
A typical format of the user story: As a <user role>, I want <goal> [so that <reason>].
- The user role represents a customer of the game (e.g., a player, a truck driver) or a developer in the production pipeline (e.g. a designer, a programmer) who benefits from this story;
- The goal of the story is a feature or function in the game, tool, or production pipeline;
- The reason describes the benefit to the customer or user when this feature or function is used (optional).
Since teams complete one or more user stories per sprint, they need to be sized appropriately. However, every large feature should not be split into sprint-sized stories at the start of the project because this would create too many stories to be practically managed by the product owner. User stories that are too large to be accomplished in a single sprint are called epics. Sometimes a number of related user stories are gathered together in a theme, which are beneficial for aggregating user stories for estimating.
Level of detail in a user story can be achieved by
- Decomposing a story into smaller substories (may create too many unnecessarily small user stories); or
- Listing these substories as conditions of satisfaction (CoS). CoS help the team understand the ultimate goal for every user story and avoid delivering the wrong feature at the sprint review. The team should verify whether the CoS are met by running the game and ensuring that behaviors described exist.
Qualities of a good user story (INVEST):
- 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.
- 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.
- 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.
- Estimatable
- Stories need to be estimated. This requires knowledge about what and how it will be built. If not enough is known or the scope of the story is too large, then the story cannot be estimated well enough.
- 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 (e.g. a group of minor bug fixes).
- 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. This is best achieved using the conditions of satisfaction.
Spikes (or tracer bullets) are special timeboxed user stories that are aimed 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.
Big advantages of user stories:
- Facilitate face-to-face communication among the developers and between the developers and the product owner;
- Everyone can understand user stories because they are terse and are always written to show customer or user value.