In the Scrum method of agile software development, user stories are how work is expressed in the backlog. How a team chooses to write their user stories is a matter of preference, but the user story should always be written from the perspective of the end user. That is, team members are encouraged to think of their work from the point of view of the consumer who will use it (hence the “user” story). A team might frame a story as a noun or, more specifically, as a feature to be incorporated into a product, such as “text messaging” on a cell phone project or “speedometer” for a car manufacturer. Or the story could be expressed in a sentence or phrase, such as “debug the 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 often written like this: “As [end user role]Desire [the desire] so that [the rationale].
For illustration without placeholders, consider how a user story for a developer working on a PC calculator app might express the work. First, you would need to know who you are coding the app for: a PC user. Second, you would want to determine what the PC user would want to use the application for: to have a convenient pre-packaged calculator application. Finally, you would like to state 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 indicate that the logic would be to add, subtract, multiply and divide, or simply add value to the product. So the end-user story might look something like this: “As a PC user, I want a calculator with basic functionality on my PC so that I can perform basic math conveniently and improve my overall experience.”
In conclusion, user stories are a way to document requirements from the perspective of the end user. 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 guiding the story to reflect the wishes of the end user, user stories help developers stay focused on what the customer wants.