Knowing how to write good users stories is essential when writing requirements in agile. In this brief post, I will review how to write user stories. A user story is a high-level definition of a requirement, written in a way to provide just enough information for developers to implement a piece of functionality. They should only be large enough to fit on an index card, post-it note, or an electronic agile board.
User Story Format
User stories represent the end users perspective. They describe a feature as perceived by the user, written in a first person voice. A user story follows this format:
- As a <insert role or persona here>
- I want <something>
- So that <I get a benefit I want>
Notice how the user story uses a first person format. This forces the team to identify the user and the business benefit for each piece of functionality. It tells who uses the system, what work the system performs, why this is valuable to the customer.
User Story Example:
Example 1: As a customer, I want to be able to provide a date, an origin and destination city anywhere in the world, so that I can get a list of flights between those two points on that day.
Example 2: As a traveling instructor, I want to submit my expenses from my laptop through any internet connection , So that I can get reimbursement in a timely way.
A user story defines an expected result in functional terms. They do not tell the developer how to design the solution and are as brief as possible. to serve as a placeholder for conversation.
Three C’s of User Stories:
User stories serve as a placeholder for a conversation between the development team. Remember the following agile principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Each story contains 3 elements that facilitate conversation: The Three C’s of User Stories: Card, Conversation, and Confirmation:
- Card: An index card or post-it note is the written medium for user stories. This forces the team to have a conversation versus lengthy requirements documents no one will ever read.
- Conversation: Developers have conversations with the users to allow mutual understanding of expectations.
- Confirmation: Confirms the conversation between the users and developers led to understanding the user story.
INVEST in your User Stories
The INVEST acronym is a checklist to assess the quality of a user story. If a story doesn’t meet one of the criteria, you may want to rewrite it.
Decomposing User Stories
Decomposing user stories happens jut in time. The lowest level details are not elicited until the last possible moment as the team gets closer to pulling a story into the next sprint. As the upcoming sprint approaches, the user stories are then broken down into tasks.
An agile project will have three basic hierarchical levels: Epic, User Story, Task. There isn’t one right way to structure the requirements level, the diagram in Figure 1 below shows the simplest way:
Summary
User stories are a simple way to capture user requirements in agile. Knowing how to write user stories allows you the ability to facilitate conversation between users and developers.
If you would like further information on user story writing or have any questions, please contact us.
If you like this post, please share using the share buttons below: