View

Software development acceptance criteria examples

In software development, our ultimate aim is always to satisfy a client. When a client approaches a software development company with a project, they have a set of ideas in their head about what they want for that project. If we can match these ideas to the best of our ability, we will have one happy client. 

However, it isn’t always as easy as this. If we could get right what a client wants every time without fail, that would be incredible. In reality, it takes a little more work and precision to ensure we are all on the same page. 

This is where acceptance criteria come in. 

In this blog, we are going to tell you all about acceptance criteria in software development. What it means, why they exist, and how you can use them to your best advantage. We will also include some examples so that you can best understand what we are talking about.

Let’s start with some definitions.

What are software development acceptance criteria?

The way in which we ensure we are on the exact same page with a client for their software development project is to use user stories and acceptance criteria. 

User stories help us clarify what our requirements for the project are, and then software development acceptance criteria help us lay out the conditions needed to satisfy these user story requirements.

Essentially, the acceptance criteria help us to frame how we will complete the project in the way it was intended to be completed. They exist to make sure that all the development we do has a purpose and is a direct match for the requirements set out by the client. 

The reason that we need acceptance criteria, as well as user stories, is that user stories can often be vaguer than we would like. Say, for example, your client states that they want an app that can organise your daily tasks. This gives us an idea of where we are headed with the project, but it isn’t exact and concrete enough to help us work efficiently towards a clear goal. It leaves room for misinterpretation and unmet expectations. 

Acceptance criteria, on the contrary, help us really nail down what we are talking about and how we are going to do it.

The structure of acceptance criteria 

There are two different ways in which you can structure your software development acceptive criteria: 

 

Checklist format: The first, and simplest, way to structure your acceptance criteria is simply in the format of a checklist. You can write out a list of necessary conditions on a ticket and then that ticket will either pass or fail, depending on whether the conditions have been met. This structure is rule-oriented. 

 

Given/When/Then: The given/when/then formula is popular in many areas of software development and is scenario-oriented. It helps us to frame what we need to create in order to get the specific results we want. In the case of acceptance criteria based on a user story, this formula might look something like 

 

User story: I want an app that organises my daily tasks by time due

Acceptance criteria: Given a user navigates to the task manager homepage

                                 When a user inputs tasks

                                 Then the system prioritises them via earliest time

 

In both of these structures, we are working towards meeting the targets set out by both the client and the development team collaboratively. Both options help streamline the development process into easy-to-follow, structured processes. Using acceptance criteria means, in theory, any member of the development team should be able to pick up a ticket and work through it with purpose and aim.

A longer example

Let’s go for another example to show exactly what we mean by this. Let’s look at an example from eCommerce.

The user story for an “add a review” feature on an eCommerce site would be:

 

As a validated customer

I want to able to review a product

So that I can give feedback 

 

The acceptance criteria for this piece of functionality would be:

 

Scenario: Validated customer leaves a review on a listed product

 

“Given I’m in a role of validated customer

When I open the page with a specific product

Then the system shows the “Reviews” section beneath the product with a list of reviews added by other users

And the system shows the “Add a Review” field in the top of the “Reviews” section

When I fill in the “Add a Review” field with my review

And I click the “Submit” button

Then the system saves my review

And the system shows my review in the top of the “Reviews” section

And the system shows my username on the left side from my comment

And the system shows “Remove” and “Edit” icons opposite my comment”

 

This more detailed view of an acceptance requirement ticket shows us how it would be to work through the process. It is very precise and lends itself to accurate results. If a client requests to leave a review feature on their eCommerce site, following these acceptance criteria is guaranteed to give them the results they want. 

Best practice of acceptance criteria in software development 

When it comes to writing acceptance criteria, there are some systems of best practice that need to be established in order for them to work as they should. There can be variation in who writes acceptance criteria, some projects may have clients writing them, whereas others will leave this task to product managers and business analysts. As long as someone has ample technical knowledge and follows these elements of best practice, they can write acceptance criteria if they so wish. 

Acceptance criteria should: 

  • Be clear and concise
  • Be written in active voice
  • Avoid negatives and “not” sentences
  • Avoid too many technical specifics
  • Be accessible to a range of team members
  • Be achievable 
  • Not be too narrow in scope
  • Be easily tested
  • Be agreed upon collaboratively between development team, client, and stakeholder

The goal of acceptance criteria is not to come up with complex and technical requirements that can only be understood by tech leads. They should be small and useful pieces of information that help structure development. They should always be a help and not a hindrance. 

If we follow the acceptance criteria structures and pillars of best practice, we are on to a winner. We can see our projects run seamlessly and efficiently towards end results that are satisfactory to everyone involved. 

Isn’t that what we all want to see in any software development project?

Find a team of experts to build your project

 

If you are ready to take your next idea to the creation stage, you are probably looking for the best team to help you.

 

At 6B, we are an experienced and skilled software development company ready to take on your next project. Our unique blend of skills and knowledge help us build every project to the exact requirements you have in mind. 

 

To see your dream software come to life…

 

 

Get in touch with us at 6B today

Looking to accelerate your next digital project?

Do you want to work for us or do you have an idea in mind where 6B can help?