Russell Pannone and Geoffrey Bourne write that at first glance, a User Story looks simple, almost trivial. However, it contains the essence of the project deliverables. It describes the who, the what, and the why of every piece of delivered functionality.
This article is part two of a two-part article excerpted from an upcoming book, being written by Russell Pannone and Geoffrey Bourne to be published by Addison-Wesley. This will be the first book to provide agile-lean product development practitioners with a pragmatic, clear, and concise collection of answers to their questions about agile and lean product (system-software) development.
In Part 1 we covered:
- The tie between writing agile requirements using stories and an agile requirements positioning statement
- What is a user story
- Why user stories
In Part 2 we will cover:
- Writing a user story
- How much detail you need
- Writing acceptance criteria
- Running a story brainstorming session
Writing a User Story
At first glance, a User Story looks simple, almost trivial. However, it contains the essence of the project deliverables. It describes the who, the what, and the why of every piece of delivered functionality.
The typical format for a User Story is:
As a <who/role> I want <what/action> so that <why/reason>.
As in any good requirement, the User Story contains “what I want.” However, more often than not requirements forget the all-important “who wants it” and “why.” Defining the “first person” who/role puts you in the shoes of the user wanting the Story and guides you in asking the right questions about the context and reason for the request. This leads to clarity of the Story’s value and bounding its scope by defining the “why/reason.”
Hopefully you can see the above requirements leave a lot of unanswered questions. Now let’s look at some examples of well-written User Stories based on the Soulful Winery vision document contained in Appendix A:
- As a site-administrator, I want to be able to add, change and delete wine lists so that current wine information is displayed on the website.
- As the application, I want to track all changes for each customer, so that there is an audit trail available at any time.
Note: As depicted above the “who” does not always have to be from a person’s point-of-view. The who can represent a non-human role that interacts with the product (system-software).
- As a customer, I want to be able to enter my billing information, so that I can purchase wine from the winery website.
- As a customer, I want to be able to see my discounts after I make my wine selections, so that I can verify I received the correct discount.
- As a customer, I want to view a list of wines, so that I can see what's available for purchase.
- As a customer, I want to be able to select wine by different categories, so that I can specify the wine variety I wish to purchase.
- As a customer, I want to be able to enter my shipping information, so that the winery can deliver my order to my address of choice and knows where to ship my order.
Note: I if the w hy/reason is intuitively obvious it can be omitted, but do not do this hastily. If the why/reason is not understood there is a very good chance the Story does not represent a needed value-adding feature.
How Much Detail Do You Need?
One of the challenges you will face is learning how to include just enough detail to minimize ambiguity and uncertainty. The more experience you have working with Stories the easier this will become.
A Story should contain just enough detail to enable the team to determine what the solution involves and what it will take them to deliver the Story. Anything less makes estimating difficult. Anything more wastes time and energy on details that will