User stories are simple, one-line benefits statements of a valuable function. Prior to writing the user story, conduct user surveys and interviews to query the user about needed functionality. Start by writing a customer journey, stated in incremental stories, on 3x5-inch cards or Post-it notes. These cards can be put immediately into production or provide context for the backlog.
In the case of user story mapping, you can display Post-it notes along a conference room wall so the entire team can see it and work on long-range planning.
There are a few techniques you can use to help write the stories you need. A common technique is the Role-Feature-Reason or Benefit (RGB) structure that you construct by filling in the blanks of this sentence:
As a (user/persona/customer), I want to (do something) so that I will (receive a benefit).
Adding to the RGB question is a method pioneered by Ron Jeffries which highlights his ?three C approach:?
Card: Write the answer to the RGB (described above) on the card.
Conversation: The limited detail on the card is the basis of a promise fulfilled by the second C. During this phase, the team discusses the details and establishes a definition of ?done.?
Confirmation: This is the result of feedback that determines the test or acceptance criteria. This acceptance criterion is often written on the back of the card and is used as the initial checklist during future meetings to determine completion.
First introduced in an article by Bill Wake in 2003 and popularized by Mike Cohn?s book, User Stories Applied for Agile Software Development, the acronym INVEST is a method to evaluate user stories. INVEST criteria is as follows:
Independence to develop in any sequence.
Ability to Negotiate the extent of the story to develop.
Provides Value to the user or business.
Can be Estimated for completion.
Is Small enough to design, code, and test in a single iteration.
And finally, can be Tested.
