In Agile Software development, requirements are captured from the point of value of the user. There are usually several actors that are acting on the system called User Personas (example: User, Admin, Customer, Supplier etc). It should not be written from a developer or tester or manager’s perspective.

The Product Owner along with team usually writes user stories and the Product Owner explains the User Story to the development team, and clarifies any questions the team might have.

User stories can be written for functional characteristics with acceptance criteria which should be initially written by the Product Owner and later reviewed along with the team.

User stories can be also written for technical stories which indirectly derive a value to the functional user stories (example: Java Update, Hibernate Upgrade etc).

The tester can also be part of the team discussion along with the Product Owner and help team to bring up any missing points.

He also take help of Product Owner to review the test cases he writes for specific story to validate his understanding.

A tester many rely on INVEST acronym for understanding and analyzing user stories

• Independent:  avoid introducing dependencies, combine to deliver in a single Sprint
• Negotiable: stories are not contracts; need flexibility to adjust how much gets implemented
• Valuable: how the value to users, customers and stakeholders
• Estimable:  team needs enough details to estimate the effort
• Small: stories, sized appropriately for completion in a Sprint (includes testing)
• Testable:  meets customer needs; understood by all, automate as much as possible

Example of a User Story with acceptance criteria is given below:

Story: As a customer, I would like to have an email sent to my normal email address when my account goes into overdraft so that I know that I need to put money into my account.

Acceptance criteria: When and account goes into overdraft, the system will issue a secure message to the user’s account, then the system will:

1. Check to determine if the user has a valid email account in their file
   • If there is a valid email address on file, the system will send a message to that address indicating that a message is available
   • If there is not an email address on file, the system will flag the account as incomplete
2. The message sent to the customer’s email address will match the text provided by marketing
3. The email sent by the system will be formatted for HTML viewing and will match the graphic design specifications   sent by marketing
4. The email will contain a hyperlink which allows the user to jump instantly to the online banking site

The 3C method of a User Story is described as below:

• Card: The topic of the backlog item, the high level description of the desired system behavior.

• Conversation: Detailed requirements are identified throughout planning. This is a dialog between the Product Owner, Scrum Master, scrum team, and others.

• Confirmation: Recorded acceptance criteria that insure the backlog item is completed to the specifications of the Product Owner.

There are different ways of writing user stories, however regardless of the way, the acceptance criteria should be just enough to understand the primary requirements.

Other popular articles:

• What is Acceptance Test-Driven Development in Agile Methodology?
• What is Planning Poker? Effort estimation in Agile methodology
• What are Test Levels in Agile methodology?
• What is Definition of Done? Test Levels in Agile software
• What is Release and Iteration Planning in Agile methodology?