User Stories

User Stories are descriptions of a feature written from the point of view of the final user. They focus on the value that the feature will deliver to them.

The structure of a User Story is typically the following:

As a [type of user],
I want [an action]
so that [a benefit].

You can have more than one I want statement if the user has multiple needs related to the same feature. Same for the so that statement, you can have multiple benefits for the same action, but it is not recommended.

Characteristics of Good User Stories

• Keep it simple and concise. Should be completed in a single sprint (2 weeks)
• Make clear what is the value to the user.
• Independent, so it can be developed and delivered independently.
• Open to discussion and changes.
• Help to keep the focus on the user needs, by using the user's language.
• Avoid technical specifications.
• Testable, with clear acceptance criteria.
• Flows are highly recommended to navigate through complex user interactions.

Acceptance Criteria

Acceptance Criteria are the conditions that a User Story must satisfy to be considered complete. They act as a checklist that the development team can use to verify that the User Story has been implemented correctly and the requirements are clear.

They are also the bridge between all teams involved, from the Product Owner, Developers, QA team and the stakeholders.