In the Scrum method of agile software development, user stories are how work is expressed in the backlog. How a team decides to write their user stories is a matter of preference, but the user story should always be written from the end-user perspective. That is, team members are encouraged to view their work from the point of view of the consumer who will use it (hence the “user” story). A team can articulate a story as a noun or, more specifically, a feature that will be embedded in a product, such as a “text message” on a cell phone project or a “speedometer” for an automobile manufacturer. Or the story could be expressed in a sentence or phrase, like “debug GPS tracking system.”

Many Scrum teams have adopted Mike Cohn’s user story template, in which a single sentence identifies who the end user is, what the end user wants, and why. This user story model is usually written like this: “How [end user role], I want [the desire] so that [the rationale].

As an illustration without placeholders, consider how a user story for a developer working on a PC calculator application might express work. First, you would need to know who you are coding the application for: a PC user. Second, you’d want to determine what the PC user would want to use the app for: to have a convenient calculator app prepackaged. Finally, I would like to indicate why it is important for the PC user to have this application. This is perhaps the least clearly defined information, but it can be assumed that the developer could claim that the reason would be to add, subtract, multiply and divide, or simply add value to the product. So the end-user story might read something like this: “As a PC user, I want a calculator with basic functionality on my PC so that I can conveniently perform basic math operations and improve my overall experience.”

In conclusion, user stories are a way to document requirements from the end-user perspective. Although stories can be written in a number of ways, Mike Cohn’s model is of particular value to Scrum development teams because it provides the most information about the story, including who it is being built for and why. By orienting the story to reflect the wishes of the end user, user stories help developers stay focused on what the customer wants.