Welcome to NatureServe Web Services. Web Services: NatureServe Web Services provide direct access to NatureServe's growing menu of on-line products and services.

Home

For Data Providers

Technical Resources

Using User Stories for Software Development


What Does a User Story Look Like?

  • Hand-written on the front of the card. Tip: use the template {actor - goal}.
  • Owner/writer's name in the lower left corner.
  • Rating from 1 - 5 in the lower right corner based on owner's gut feeling of its value:

    1 = critical: this service will not be useful without this
    2 = fundamental: it'll cost more to use the service than it'll benefit without this
    3 = good feature: seems like this should be doable, so do it!
    4 = uncertain: not sure, but feels important
    5 = cosmetic: not a high priority/do it if it's easy

 

What Is a User Story?

A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories typically take the format actor - goal:

actor - a group of users who interact with the system in similar ways or for similar purposes; can be a role.

goal - what the actor wants to accomplish; it is just detailed enough to need further conversations.

User stories are composed of three aspects:

Card

  • A written description of the story used for planning and as a reminder to have a conversation.
  • Represents rather than documents requirements.

Conversation

  • Conversations between owners and developers about the story serve to flesh out the details of the story.
  • Occurs "just in time" (not months or years before implementation begins)

Confirmation

  • Acceptance tests that convey and document details and that can be used to determine when a story is complete.

 

What is not a User Story?

  • User stories are not shall statements.
    • Shall statements reorganize the atomic units of a user story by their atomic characteristics (and are thus tedious and time consuming to write and to read).
    • User stories maintain their composition, so the value to the customer is always known.
  • User stories are not use cases.
    • Use cases are like contracts that customers and developers agree upon. User stories facilitate release and iteration planning.
    • Use cases are typically written as a result of analysis, where user stories are written as notes that can be used to initiate analysis conversations.
  • User stories are not scenarios.
    • Scenarios are characterized by a setting, an actor, goals or objectives, actions and events.
    • User stories are concerned only with the actor and goal or objective, in manageable units.

 

Submit a New User Story

Submit a user story for Internet Data Delivery.



Copyright © 2005
NatureServe

NatureServe.org Contact Us Site Map Acknowledgements