Acceptance Criteria in Agile

An agile development team might be familiar with acceptance criteria.  But sometimes teams face complication separating acceptance criteria and test combinations. Acceptance criteria is -“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” (Microsoft Press) A set of statements which describes user’s requirement or features and functionality of an application.

User Stories:

In agile software development, Product Team write the user story to describe the feature requirement, and Development Team implements the story. Basic user story syntax –

As a Project Manager, I want to add project members to my project, so that the project members can register hours on the project

But a good quality story can’t explain the whole requirement of the feature to the Development Team. So that the development process can’t be done properly using the user stories only. The user story is incomplete without acceptance criteria.

 

Acceptance Criteria:

There are few rules that helps to write acceptance criteria –

  • Thinking as a User

Acceptance criteria are statements of requirement. So we need to think from user perspective. How the user would want the feature to be, how the user would feel when using the product. How the product can be as expected by the user. Users age, education, level of understanding matters when writing the acceptance criteria.

Example:

“Project Manager wants to select the project members, which can be showed in the project dashboard”

This gives a better idea to the development team to understand the feature requirement and to implement it.

  • Functional, Nonfunctional and Performance Requirement

It is important to write the acceptance criteria based on Functional, Nonfunctional and Performance Requirement. Also both positive and negative scenario.

Example:

For the project member selection feature

Functional: Successfully added project members should be listed as a member to a specific project with a message.

Nonfunctional: The message should be a popup message. Should display in the middle of the screen.

Performance: The message should display within 5 seconds.

  • Simple Language

Acceptance criteria should be in simple language. It should describe “What to implement” not “How to implement”.

Example:

Should be like –

Project Manager can accept all the project member request for his/her project

Not like –

Project Manager can click on approving button which displays against the pending requests of the team members.

  • Do not mess up with Test Combination

It is very important to not to mess up the acceptance criteria with the test combination.

Example:

User Story:

As a Project Member, I want to see my Average Working Hours, So that I can know my Average Working Hours for a week.

Acceptance Criteria:

  • Display average working hours for the current week

Test Combination:

  • Display average working hours up to 2 decimal points
  • If Project Member haven’t worked for the week display 0.00

Acceptance Criteria makes the scope to define the story more clearly and understandable to the development team. So that it helps to build the right product and add more business value to it.

Leave a Reply

Your email address will not be published. Required fields are marked *