Writing Effective User Stories

Writing Effective User Stories

User Stories are a great method to express stakeholder requirements, irrespective of the methodology we use for the project. A user story is written from the perspective of a specific role the person intiating the action. It should provide the single outcome required of a signle interaction.

1. Keep the User Story Simple

A good structured user story will have a single action to achieve a specific goal. It should be without words or conditions like "and" "or" "if" "else" "unless" "except", so that requirement and goal is clear.

2. Keep WHAT is required not HOW

The user story should focus on what is required out of it, not how to do that. How to do that, may include technlogy used, and other similar things which may have to be dicided on a project level or developer level.

3. It should be RELEVANT

User stories should be relevant to the project requirements and aligned with the Project Charter and Scope.

4. No Ambiguity

User stories should avoid the use of ambiguous words to make it simple and clear for all the members so various members won't interpret it differently.

5. Measurable Non-Functional Requirements

When we add Non-Functional Requirements, it should be added with a measurable option than using an expression. For example instead of describing a requirement of "the web application should be reliable" we can rewrite as "the web application should be able to serve 1000 requests per minute"

5. Measurable Non-Functional Requirements

When we add Non-Functional Requirements, it should be added with a measurable option than using an expression. For example instead of describing a requirement of "the web application should be reliable" we can rewrite as "the web application should be able to serve 1000 requests per minute"