Creating User Stories

You start this process by writing a specific user story. This story follows a very specific format:

As a [user role]

I want [feature]

so that [benefit]

In order to generate the required number of user stories to best describe your requested capability, you can add as many User Story Titles and Conditions of Acceptance as you need to by clicking on the + (plus) sign below the “Conditions of Acceptance” field on this form.

Examples of user stories can be:

  • As an author I want a spell checker so that I can avoid spelling errors in my documents
  • As a shopper I want a wishlist so that I can remind myself of things I’d like to buy in the future
  • As a salesperson I want a sales forecast report so that I can ensure I’m on track to hit my quota

Example of a User Story “Conditions of Acceptance” entry:

For the purposes of this example, we’ll use the example of the “spell checker” story (the first one of the user story title examples). The following list of conditions would need to be met for the benefits of the story title to be satisfied.

Example Conditions of Acceptance:

  • I can check spelling for my entire document
  • I can step through each spelling error one at a time
  • I can see suggestions
  • I can replace my word with a corrected word
  • I can add words to my dictionary
  • I can check spelling in English

User Stories

A user story is a description of a feature that is very lightweight, easy to understand, and quick to write. One of the key benefits is the ability to describe the vision of the project to the whole team, without spending weeks creating detailed requirements.
  • Please specify your email address to help us identify/locate your user stories. (PS: We will not add you to our email list when you use this service!)
  • User Story

  • Describe the role of the user who will benefit from this requirement

    Examples include:
    "paying member",
    "logged in user who is a paying member",
    etc

    "As a "...

  • Type the single requirement you want to resolve. Keep in mind that you can come back and add multiple user stories, so the more specific the description of each is, the less time we will spend going back and forth on what you meant - i.e. "a spell checker" vs "an editor" - .

    "I want to "...

  • Describe the benefit(s) - aka "Return On Investment" - you expect the requirement will provide. A benefit should be something specific/tangible the user role will receive from the resulting feature.

    "So that" ...

  • Conditions of Acceptance

  • What are the list of conditions that need to be met by the [user type] to realize the [benefits] of the [feature]?

    Create as long of a list of single-sentence conditions (see the above example) as you need to

  • +-
  • This field is for validation purposes and should be left unchanged.

Leave a Reply

Your email address will not be published. Required fields are marked *