|
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.
|