A user story is a technic to capture a description of a software feature from the end-user perspective. The user story raises the question of why the user needs this functionality, and how they can interact with it.

Thanks to user stories there is greater alignment in the delivery of this functionality as user story builds shared understanding of what problem need to be solved.

Tips on writing good user stories

• A product owner should not write a user story by herself - it should be discussed with a development team to reduce overhead, mitigate risks and ensure alignment between product and engineering.
• A user story should be concise and straightforward. Avoid confusing terms and focus on what's important.
• A good technic to write a story is using roles. The goal is the benefit that the user of a specific role wants to achieve or the problem she wants to solve.
• Acceptance criteria are a set of conditions that have to be fulfilled so that the story is done. Each with a clear pass/fail result.
• Acceptance criteria make the story testable.
• Each team member should have a complete understanding of the user story and acceptance criteria.
• There are two formats of acceptance criteria that can be mixed or used independently:
• scenario-oriented (given/when/then) - “given some precondition, when I do some action, then I expect some result”
• rule-oriented (checklist) - a set of rules that describes the behavior of a system.
• Good user story will contain few key examples

Example user stories

User story:

As a traveler, I want to see if a tax is included in the room’s price so that I can be more informed about my hotel reservation

Acceptance criteria:

• Given a hotel returns room rates with $0 taxes for 1 night, then when the user hovers over the nightly rate, the window should appear with the details of the nightly rate and say that taxes and fees are “Included“
• Given a hotel returns room rates with $0 taxes for multiple nights, then when the user hovers over the nightly rate, a window should appear with the details of the rate and say that taxes and fees are “Included”
• Given a hotel returns room’s rates with a value for taxes for 1 night, then when the user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees
• Given a hotel returns room’s rates with a value for taxes for multiple nights, then when a user hovers over the nightly rate, a window should appear with the details of the rate and the actual value of the taxes and fees.

Lifecycle of a story

1. PM works with the team to define a new story that covers "WHAT" the effect of the Story will be
2. It should be unambiguous and include acceptance criteria (preferably examples)
3. New Stories are placed in backlog without estimates and not groomed
4. Stories are take from backlog and investigated by members of the team (from 1 .. team size)
5. Outcome of grooming is a definition of "HOW" the "WHAT" will be implemented along with estimate.a. This should leave no questions to be answered by a dev teamb. The team should be aligned on HOW specific story will be implementedc. As "HOW" is defined, team estimates the story.
6. Groomed and estimated tickets are available to be pulled into a future sprint
7. Sprint is simply execution of the "HOW" including writing and automated tests or manual test cases