User stories

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Ongoing sprint.png This article covers an agile concept!

Agile concepts are currently evaluated by the development team to help us stay focused and make better progress on a more steady basis.

This article describes what user stories are and how they're utilized in PARPG development.

Contents

What are user stories?

User stories are a specific form of feature requests that can be used to fill the product backlog. If user stories reside in the product backlog, they're also called product backlog items, or short: PBI.

Why write user stories?

Due the form of the user stories, they help us to think about three important questions:

  1. What kind of feature do we want?
  2. Who would benefit from such a feature?
  3. Why do we want this feature? What kind of value does it provide?

Due their simple form, user stories can be understood by everyone on the development team and even by community members who are not directly involved in the development process.

User story format

User stories usually follow this format: As a <user role>, I want to have <goal> [so that <reason>].

User role is the point of view the story is written from. The goal is usually some kind of feature or tool the user benefits from. The reason states the actual benefit to the user.

Stating the obvious

While it's often a good idea to state a reason for a user story to express the value of a requested feature, sometimes this isn't needed as the value is too obvious. Let's take this user story as example:

Multiplayer support
As a player, I want to play against other players over the internet and in local area network.

This user story lacks a reason but it actually wouldn't benefit from having one. If multiplayer support is one of the planned key features of this product, simply don't add a reason as everyone on the team understands why you want to have multiplayer support.

Epics

Epic user stories, often shortened to just epics, are very high level user stories about features of a game, the asset pipeline or project infrastructure. When a new project starts, the product backlog is filled with some epics that are meant to be part of the product and they're prioritized by the product owner. Epics can't be tackled in a sprint, they're simply too epic to be implemented in such a short timespan. In sprint prioritization the product backlog is prioritized and a small number of high priority epics (usually just two) are broken down into smaller user stories. The user stories have be small enough that they can be tackled within one sprint.

INVEST

User stories should follow the INVEST principle:

Independent
User stories should be independent from other stories in the order they are implemented. If dependencies can't be avoided, they have to be clearly visible so the team is aware of them. This can be implemented via Trac's blocking/blockedby feature.
Negotiable
User stories are neither design documention nor a long list of implementation details. They rather state a goal but leave implementation details to the sprint team that works on the user story. This way the sprint team is empowered to be creative and approach the user story in the way that feels best to them.
Valuable
User stories should always express value. If they don't express value and the value isn't obvious, the user story needs to be refined.
Estimatable
User stories need to be estimatable so the sprint team has at least a vague idea how much effort it would take to implement this user story. If a user story can't be estimated, it needs to be broken down into smaller user stories in sprint prioritization. Furthermore spikes can help to estimate user stories by creating knowledge about it.
Sized appropriately
If a (epic) user story doesn't fit into a single sprint, it needs to be broken down into smaller user stories in sprint prioritization.
Testable
There has to be a way to verify if user stories have been successfully tackled during a sprint. The best way to ensure this in case of ambiguity, is to add conditions of satisfaction to the user story.

Conditions of Satisfaction

Conditions of Satisfaction or short CoS are sometimes added to user stories that get tackeled in a sprint so the team can decide if a feature has actually been completely implemented and can considered to be done. These CoS are usually added to the user story when it's moved from the product backlog into the sprint backlog. CoS have to be testable.

Example

User story:

Authentic non-player characters
As a player, I want that non-player characters react authentically to my behaviour.

Conditions of Satisfaction:

  • When I provoke an aggressive NPC, he attacks me.
  • When I drop an item on the ground, an NPC might pick it up if it's valuable to him.
  • When I have a reputation of being a child killer, an NPC might refuse to talk to me or even openly attack me.

User story roles

  • Player
  • Developer
    • Programmer
    • Game designer
    • Graphics artist
    • Project manager
    • etc.

User story types

User stories can be about:

  • Features of the game
  • Tools and/or documentation that is part of the asset pipeline
  • Project infrastructure in general

Examples

Crafting
As a player, I want to craft items.
Combat
As a player, I want to attack other non-player characters.
Graphical assets import pipeline
As a graphics designer, I want to have a tool to easily import my rendered assets into the game.
Distributed version control
As a programmer, I want to work with a distributed version control system so that I can commit locally and have an easier time to merge my changes.

Additional reading

Personal tools