Build the product right while building the right product
Acceptance criteria are an important part to the iterative planning process when working under an agile methodology. Having clearly defined acceptance criteria, that are written in line with your user stories, is an essential way to ensure you and your team know when the story has been completed.
Acceptance criteria helps to remove the confusion and uncertainty in the team and it is important to have the right people in the room when creating these. Each role has it’s place in the agile team, each with a set of skills that add to the quality of the acceptance criteria.
We can avoid nasty surprises at the end of the sprint, by ensuring we have clearly defined acceptance criteria before any code has been written.
We can ensure that we are building the product right, by constantly reviewing and checking off the acceptance criteria, we can ensure we are building the right product by having the discussions with the people that matter before any code has been written.
What are Acceptance Criteria?
Acceptance criteria are statements that are used to define requirements, these are done from the point of view of the user. These are created to determine when a story is done and is working as expected.
It is important to get the right people in the room when outlining acceptance criteria, these can include Business Analyst, Product Owner, Tester, any stakeholders that are important to the project. The conversation which occurs when creating and coming up with the acceptance criteria is one of the most important parts of defining acceptance criteria.
Having the right people in the room, ensures everyone’s views and particular skills are used to ensure the right thing is being built from the start. Every role has a certain skill, ensuring that they are involved in the beginning gives more opportunity to build the right product from the beginning.
Each acceptance criteria statement that is defined has a clear pass or fail result.
When are acceptance criteria defined?
Acceptance criteria is defined at the start of the project, before any code has been written. You can always change the acceptance criteria as you go, but having clear goals and clear guidelines of what a pass or failure are for each task, is important.
Adding acceptance criteria at the beginning of the project allows the discussions to be had around what is being built, and what would be considered as completed for the task.
What makes good acceptance criteria?
Good acceptance criteria should be clear and easy for anyone in the team to understand. They describe the what, not the how. They have a clear understanding of what a pass or failure will be. They cover all points from the task, story or feature. Acceptance criteria is written in a high level and should not be written in gherkin language.
- Ensures everyone in the team know when they are done
- Removes confusions and assumptions
- Created through a collaboration between key stakeholders Dev, QA, Product Owner
- Written at a high level (conceptual, not detailed)
- Created prior to code being written.
What are Acceptance Tests?
Acceptance tests are scenarios derived from acceptance criteria, these look to prove that the acceptance criteria has passed, you can have multiple acceptance tests from one acceptance criteria.
These can then be automated. Some popular BDD tools are Cucumber and Specflow that follow a Gherkin language of Given, When Then.
While acceptance tests are a good starting point, to work out what should be tested, they are only a starting point. You should be diving in using an exploratory approach with different testing techniques, to ensure you have fully tested your feature or product.
- Proves the acceptance criteria
- Derived from the Acceptance Criteria
- Can be added to at anytime during the development phase
Without acceptance criteria your team will struggle to know when they are done working on a story or feature. When the criteria is clearly defined it is easy to then know what has been covered and when they have completed the task.
Having conversations as a team, before any code has been written, helps ensure that the right product is going to be built. With any concerns or issues raised at the time of the discussion, or as early in the process as possible, essentially the cheaper and faster it is to fix.
It’s important that the acceptance criteria are written well. Spend the time researching and learning how these should be written. If they are not well defined, then they will create more confusion.