User Story

User Stories are a technique to describe requirements from the perspective of a user using everyday language. In Scrum User Stories are used as Product Backlog items. They are written by the Product Owner.

A "User Story" captures what the user wants to achieve and why.

User Stories generally follow this template:

• "As a USER I want GOAL/DESIRE so that BENEFIT."

A User Story should be short and precise and fit on a small note card.

User Stories provide a simple and easy way of handling customer requirements, which can be product or service requirements. The intention of User Stories is to quickly capture the requirements and to iteratively refine them and break them down.

Writing User Stories

To create user stories, the Product Owner and the Developer (or just one of them) gets together with a customer. The customer formulates the user stories. The Developer may use a series of questions to facilitate the customer, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process.

User stories are not definite once they have been written down. If the Developer or the customer finds that a user story is lacking in some way (too large, complicated, imprecise), it is refined or broken down.

User stories can be combined with acceptance criteria. In this case the customer also writes down the criteria by which he will judge the solution to the user story to be adequate or not. These acceptance criteria are attached to the user story.

CCC

Card

User stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It’s used in planning. Notes are written on it, reflecting priority and cost. It’s often handed to the programmers when the story is scheduled to be implemented, and given back to the customer when the story is complete.

Conversation

The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated (usually during release planning), and again at the iteration planning meeting when the story is scheduled for implementation. The conversation is largely verbal, but can be supplemented with documents. The best supplements are examples; the best examples are executable, We call these examples confirmation.

Confirmation

No matter how much discussion or how much documentation we produce, we can’t be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds confirmation that we sorely need. This component is the acceptance test.

INVEST

Independent

One of the characteristics of Agile Methodologies such as Scrum is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

Negotiable

The only thing that is fixed and set in stone in a Scrum project is a Sprint Backlog. While the story lies in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by Scrum team members.

Valuable

The focus here is to bring actual project-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user beats one of the Agile Principles, which is to continuously deliver valuable software. Principles behind the Agile Manifesto

Estimable

If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of a Sprint. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the times, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

Sized appropriately or Small

Try to keep your user story sizes between 0-13 story points. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a Sprint Backlog becomes closer.

Testable

You should always bear in mind that a story should be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimable" above), the story should not be considered a good candidate to be part of a Sprint Backlog. This is especially true for teams employing [[Test-driven development|TDD - Test Driven Development]]