How to Write Acceptance Criteria for Kanban User Stories

The success of any product depends on meeting customer needs and requirements. It is important for any business to clearly understand and know what their customers want and need. In our Kanban user stories blog, we discussed how creating clear user stories helps development teams understand customer needs and requirements better. Acceptance criteria in user stories will help make those customer requirements explicit. User stories and acceptance criteria go hand in hand in helping development teams make successful products. 

Let’s explore how you and your team can write clear acceptance criteria for your user stories.

What is an Acceptance Criteria?

Acceptance criteria (AC) are a set of statements that define how a user story can be completed. Because of this, using acceptance criteria in user stories provides clear boundaries for the team when developing a feature. A user story will only be considered done if all the criteria in it are satisfied. This is one of the main components of a team’s definition of done. Because of this, acceptance criteria help the product team and the development team to be on the same page. It prevents miscommunication and misinterpretation. It also lessens the likelihood of rework. 

Who Writes the Acceptance Criteria?

In Scrum, the Product Owner is in charge of the product backlog and the user stories in it. Consequently, the PO is also in charge of writing the AC for those user stories. In some teams, a Business Analyst works with the PO in managing the backlog. In this case, the BA can be responsible for documenting the acceptance criteria in the user stories. In case you don’t have these roles in your team now, your best bet will be the team member who knows your client’s requirements and needs. Like in some organizations, there are product managers or a product team. You can assign one of the product team members to handle the backlog.

The acceptance criteria written by any member of the product team should be reviewed by the development team before any user story being worked on. This happens during backlog grooming. The development team reviews the user stories along with their acceptance criteria to ensure clarity and technical feasibility. During backlog grooming sessions, the development team can also raise the criteria that should be included in the user stories. Once the consensus is met, the PO or BA will write those acceptance criteria on the user stories. 

Writing Acceptance Criteria for User Stories

Now that we know what AC are, you might be wondering if there’s a special way to write them. In our Kanban user stories blog, we discussed the format for writing user stories. Is there also a format for writing acceptance criteria?

There are two common approaches to writing acceptance criteria: rules-based and scenario-based. Rules-based acceptance criteria are usually written in a list. An example of rules-based acceptance criteria is in our Kanban user stories blog. As illustrated in the example, rules-based ACs are written in a list and are descriptive of the expected behavior for that feature.

For the scenario-based approach, each AC describes the criteria through scenarios. The common format used for scenario-based AC is the Gherkin format.

Using Gherkin to Write Acceptance Criteria

The Gherkin format follows a specific syntax: 

Scenario > Given > When > Then

Here’s what each component is for:

• Scenario – Describes the action a user will undergo

• Given – Describes the context in which the scenario takes place. This could be the page or screen the user is in, the user access rights or role, or the state or condition in the app that the user is in.

• When – The action a user performs or an event that happens 
• Then – The system response or expected outcome

Cucumber, a tool that supports Behavior Driven Development, uses the Gherkin format for the tests written through the platform. One of the acceptance criteria examples that Cucumber discussed in their Gherkin reference page is:

Feature: Guess the word

  # The first example has two steps

  Scenario: Maker starts a game

    When the Maker starts a game

    Then the Maker waits for a Breaker to join

  # The second example has three steps

  Scenario: Breaker joins a game

    Given the Maker has started a game with the word “silky”

    When the Breaker joins the Maker’s game

    Then the Breaker must guess a word with 5 characters

From our Kanban user stories blog, we can derive a list of AC too. Let’s try a couple.

User Story: 

As a Lead recruiter,

I want to generate reports on how long it takes my teams to fill positions,

So that I can plan our team’s staffing needs.

Scenario 1: Lead recruiter user generates Time to Fill Positions report in .xlsx format for a certain date range.

Given-When-Then:

Given the Lead recruiter user is on Time to Fill Positions report page

And the Lead recruiter user specifies the From date to be April 1, 2021 and To date to be April 30, 2021

And selects .xlsx format for the report

When the Lead recruiter user clicks the Export button

Then the system generates a Time to Fill Positions report in xlsx format based on the date range specified

Scenario 2: Lead recruiter user generates Time to Fill Positions report in .xlsx format for a specific position = Software Developer

Given-When-Then:

Given the Lead recruiter user is on Time to Fill Positions report page

And the Lead recruiter user selects Software Developer for the Position filter 

When the Lead recruiter user clicks the Export button

Then the system generates a Time to Fill Positions report in xlsx format with the file showing only data for Software Developer HR requisitions

As you can see in our examples, the acceptance criteria are written in such a way that it’s very specific on the conditions, triggers, and expected results. They mention the fields that will be updated, the format of the report, and the buttons used by the user. This is made so there is no ambiguity on what will be developed and tested by the team.

Putting AC in Kanban User Stories

One of the good things when using Kanban cards for your user stories is you can leverage the checklists feature to list and track your acceptance criteria. So instead of putting the whole chunk of ACs in your Kanban cards description box, you can put them in checklists so that they will be used by your development team when testing if the user story has passed that AC or not. You can do this in your Kanban Zone boards. 

Here’s how that will look like for the Cucumber AC example we have above:

And here’s how our Time to Fill Positions report user story Kanban card will look like with an acceptance criteria checklist.

You can tick off any of the acceptance criteria that has passed and leave the ones unticked if they are still being tested. This is a great way to track what has been done and what’s left to be done. 

Improve Product Quality with Clear Acceptance Criteria

Having clear acceptance criteria will help you and your teams establish a common understanding of what needs to be done. This will make delivery much faster and of higher quality. But don’t let documenting restrict your collaboration as a team. The acceptance criteria are not meant to be a barrier for the development team and business team to work together. It should be used to drive conversations between the two and help towards creating a robust product that your team will be proud of. Try to refine your user stories and put acceptance criteria on them for your next backlog grooming session. You’ll find that your team will be more proactive in clarifying features and ensuring you are all on the same page on things.