The user story originated in XP but is a key tool used in Scrum to build the product backlog. The user story, written from the perspective of a user role, is used to capture the business value or benefit (to be) achieved when the user role performs an action (funct.on) User Stories are comprised of 3 elements:
- a brief statement, of the form “As a ___, I want to ____, so that ____,” used for planning (commonly written on a note card)
- conversations that elaborate on the story
- tests that convey and document details used to determine (confirm) when a story is “complete”
Ron Jeffries has named these 3 elements: Card, Conversation, and Confirmation.
Details of the story do not appear in the brief statement; these are left to be developed later through conversations and acceptance criteria between the team and the product owner. User stories are not detailed requirements specifications but are negotiable expressions of intent. They are short, easy to read, and understandable to developers, stakeholders, and users. They represent small increments of valued functionality that can be developed in a period of days to weeks. They are relatively easy to estimate.
Use Cases became common within the context of the Rational Unified Process (RUP). A Use Case is a list of steps (possible scenarios), usually describing interactions between a user and a system, related to achieving a particular goal.
The main differences between Use Cases and User Stories are:
- Use Cases are designed to get requirements elicited and recorded ahead of development (not necessarily *all* the requirements but enough to do a considerable depth of Analysis if required).
- User Stories are designed to get the requirements “Just in Time” for development and record (on the “Card” part) just enough information to decide the sequence in which the stories will be addressed, who to have the “Conversation” with when its time comes, and what the conversation will be about.
The whole idea of Agile is to dissuade people from doing the work up-front. A User Story is an ideal tool designed to encourage minimal work up-front. Remember, don’t put the requirements on the card; the card is just a placeholder for a conversation to have later between the Product Owner and the Team. The card holds just enough information to allow the Product Owner to schedule the conversation by priority.
In summary, it helps to remember this statement:
One [User Story] is a value statement, the other [Use Case] transactional. ~ Steve Adolph