On Acceptance Criteria
In a Sprint we commit to being Done when we select Backlog Items and set a Sprint Goal during Sprint Planning. How well we Refine our Backlog Items is key to meeting that commitment in-sprint, and the Acceptance Criteria are one way we capture that refinement.
Acceptance Criteria can come in many forms, and can be different for different types of Backlog Items (a good topic for a future post). An effective way of capturing Acceptance Criteria is through the approach called Behavior Driven Development or BDD. This approach defines details about the Backlog Item in groups of Given-When-Then statements, also called Gherkin Syntax.
Successful delivery depends not just on capturing the Acceptance Criteria in BDD format. You have to put in effort to make sure you are using BDD effectively, as a way to open up conversations with the Product Owner, to think through various scenarios and details, and capture all of that clearly so you can later use it when accepting the story.
The most important part of that is the conversation, and quite simply my favorite way to open up the discussion is to ask:
Tell me a story …
With a little practice you can leverage that approach to start driving into details to build out your Acceptance Criteria.
On BDD or Gherkin format
Given
This is a conversation around the setting, the circumstance, the background, behind the scenario. What has the user done before this scenario? What is the data that has already been set up? There may be multiple parts to this background, so try to get what you can. And as you explore, there might be different background scenarios, which is important to identify.
When
Ok, so now that we have the background, what is the user doing? What is the additional information the user is providing, or the actions they are taking? Again, there may be multiple steps, but take care here as multiple steps here may suggest you either have multiple scenarios, need to think through your Given statements more, or even have multiple stories that need to be split out.
Then
Here we work through expected outcomes, and turn them into concrete statements that can be used to validate we are getting the right results. Think through the details, capture as much as you can, and remember that sometimes it is as important to validate what is not there as it is important to validate what is there.
Tips
- Throughout all of your Given, When, and Then statements, do try to keep them to distinct but comprehensive thoughts.
- As much as you can, look for repeatable patterns that you can establish in your Given or Then statements.
- Expect to identify multiple scenarios. And put in special effort to try identifying edge cases, scenarios that test and even go beyond the limit of the functionality.
- Watch out for multiple scenarios that have the same Given statements. If some of the Given statements are common they may fit as Background. If they are all common except for different When statements, you may have multiple stories.
- Really think of this as the steps you will take to validate the Backlog Item. With the right tools you can even automate these steps and add to your functional test suite.
- Never use But statements. Usage of that keyword can get awkward, and potentially confusing, especially if you follow a But statement with another And statement.
On Testing Considerations
If you are working in an enterprise environment, you likely either still have separate Quality Assurance staff, or are transitioning to have that function as part of your team. Either way, you are likely in a situation where some members of the team feel the need to document separate test cases or test considerations that are in some way different from the Acceptance Criteria. Avoid this.
Why? This suggests a couple problems.
- First, the whole team isn’t participating effectively in the Refinement and crafting of the Acceptance Criteria. Whether intentional or subconscious, someone is holding back. This impacts your team unity, fostering divisions within the team.
- Second, you now have a second set of Acceptance Criteria that the rest of the team isn’t in on. The people doing the coding and configuration weren’t aware of the additional Acceptance Criteria when they were making those changes. This can lead to more testing cycles, slowing your overall delivery.
So the whole team needs to see the Acceptance Criteria as how we will test and accept the story. Building an effective practice around this can help bring the team together, improve quality, and improve your pace of delivery.
On Change Impacts
As the team is working on the code and configuration changes, they may identify other functionality potentially impacted by the changes. Usually the changes can be done in such a way that the other functionality remains intact, but it is still important to make the rest of the team aware of those potential impacts. These potential impacts should be noted in the Backlog Item, and shared with the full team when identified. This opens up the conversation, giving the team the opportunity to consider whether the current test automation will cover the potential impact, or if the team needs to plan for some other approach to maintain quality.
On Test Data
Your Acceptance Criteria should be detailed enough to outline the Given/When/Then scenarios, but in an enterprise environment there is often more that goes into effective data setup. You might be tempted to worry about those details while refining the Acceptance Criteria. This is one of those things that is OK to leave out of your Definition of Ready, and plan for as a task while working on your backlog item.