by Rivi Aspler
Devout Agile evangelists will define a user story as a short, simple description of a feature told from the perspective of the person who desires the new capability. The user story will typically follow a simple template: As a <type of user>, I want <some goal> so that <some reason>.
And furthermore, while a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur and the discussions are those that actually enrich the user stories with enough details that R&D teams can chew on.
So much for theory and now for practice….
A – You are defining a new product, that doesn’t have enough legacy definitions, neither an established UI paradigm that the PO or the Agile team can rely on.
B – You are defining an utterly complicated product that requires an intensive analysis of hundreds of user stories, using multiple points of view (personas).
C – Your organizational culture is such that it encourages written down detailed specifications.
I have found that the concise user stories are simply not enough. It is especially apparent when one or more of the following occurs:
Since all of the above is my day-to-day reality, at my company, we are using the following guidelines for a user story template.
Looking at the user story below, one can easily notice the following:
- We are using a table format.
- The left column of the table is dedicated to the ‘meta-data’ of the various definitions.
- Each user story has the same ‘meta-data’ topics listed down so that the PO and the developers can easily understand each-other.
- The user story defines a very granular scenario.
- The other user stories that complete the ‘Place an Order’ Theme are detailed in other user stories (i.e. the references to US19, US38 and US39)
- A UI design is attached since one picture is always better than a thousand words…
|Theme||Placing an Order
- Registered Shopper (Has an existing account, possibly with billing and shipping information)
- Non-registered Shopper (Does not have an existing account)
|User Need||As a user, I want to confirm billing and shipping information
|Starting Point||User has selected the items to be purchased
- The user will indicate that she wants to order the items that have already been selected.
- The system will present the billing and shipping information that the user previously stored.
- The user will confirm that the existing billing and shipping information should be used for this order.
- The system will confirm shipping and billing addresses
- The system will present the amount that the order will cost, including applicable taxes and shipping charges.
|Default Values ||For a registered shopper, the billing and shipping addresses are the ones that were defined as default addresses (US 19)
|Alternative Flow 1||US 38 – The user will discover an error in the billing or shipping information associated with their account, and will edit it.
|Alternative Flow 2||US 39 – The user isn’t a registered shopper and doesn’t have pre-defined shipping and billing addresses
To conclude, the above detailed template may not stick to pure Agile recommendations, but it does represent a win-win best practices for the type of definitions that developers practically need in order to get your story coded.
Tweet this: User Stories that Developer can Actually Work With http://wp.me/pXBON-3ls #prodmgmt #agile
- Stories about users and User Stories
- User stories should be implementation free
- My Agile Product Backlog Template
- 4 Product Management Success Stories
- Socks in awe: Customer interviews vs. User observation