“The job is done,” said the contractor, a software house.
“But I wanted something completely different!” replied the client.
“What were the acceptance criteria, then?”
Such a dialog could happen between parties that didn’t agree upon the project’s acceptance criteria before the production started. It’s a mistake that should be avoided at all costs. However, we are convinced that many providers found themselves in the situation described above more than once. It usually occurs when the team takes care of an assigned task and the client is negatively surprised by the effect they receive.
How to deal with such misunderstandings and eliminate them once and for all? By defining the acceptance criteria for each task in a backlog. This article will show you how to do it right.
The definition of acceptance criteria
Acceptance criteria are the conditions that must be met before a task can be accepted by the customer. They define what is acceptable and what is not within a project. Usually, they are agreed upon in a contract between the supplier and the customer. The criteria are typically proposed by the client. Then, they’re approved by the project manager and other stakeholders on the IT partner’s side. Besides the contract, acceptance criteria are also displayed in a visible place. This way, all the team members have constant access to them. This way, they can deliver the results that are expected.
The purpose of the document that contains all the criteria is to communicate what has to be accomplished. It ensures that all parties are aligned on how they will know when a project or a part of it has successfully been completed.
Why are project acceptance criteria important?
Because their main goal is to make sure that all sides understand the objectives and how they will be measured at the end of each stage of the production process. They also help prevent the delivery of non-viable results or features not included in the project scope. It’s a solid base for establishing a proper collaboration framework and communication guidelines to increase productivity and efficiency. Tracking progress and detecting potential issues also becomes easier thanks to setting up the right acceptance criteria.
All that comes down to one essential matter: production costs. The more miscommunications and wrong deliverables, the more work has to be put in to fix them. That means that the outsourced team will have to burn additional hours to re-write the code, test it, and do other activities dedicated to changing the features the client is not satisfied with. However, if they have acceptance criteria to follow, they can focus on getting things done instead of redoing them later.
How to define the project acceptance criteria?
The basic rule to remember before the start of each project, sprint, or task is “nothing is obvious”. Unfortunately, that means more work is required during the initial phase of designing project assumptions, but it pays off later. With several times fewer difficulties, as well as time and budget allocated to suitable activities, stakeholders don’t have to waste their resources on fixing problems later on.
We’ve already established why acceptance criteria are an essential element of each IT collaboration. How to create them for a brand-new project? We’ve prepared a checklist of the questions we use to build lists of acceptance criteria for our collaborations. It showcases what we pay attention to and has to be discussed before the production begins.
Setting up acceptance criteria based on an example
Let’s analyze a seemingly simple example. One of the most basic features in most IT systems is logging in. The user story in accordance with the agile approach to software development would sound something like this: “As a customer, I would like to be able to log into the system to be able to use all of its functionalities.”
Now, let’s prepare the acceptance criteria for this task.
When do we consider that the brand that offers a particular software solution provided a properly functioning login feature? In theory, it seems that it would be enough to just be able to log into the system. In practice, there are so many variables to consider:
- Logging in with a username or an email?
- Can they log in with a single sign-on, e.g. with their Google or social media account?
- Or maybe the system should be able to distinguish these two options?
- Should the password be entered on the same screen as the username/email or on the next one?
- Should the login require two- or three-factor authentication?
- After logging in, where the user should be taken? What is the specific place in the system they should land in?
- If they fail to log in, will the system inform them what went wrong and what they should do differently?
- Should the system suggest the possibility to save login data in the browser’s memory to simplify the process next time?
Being precise is the main goal here and that’s what every software house client expects. The list above is just an example. It can be expanded with a lot of additional questions and problems to solve. The product owner should communicate the business requirements before the project starts. This way, all the involved parties can prepare a detailed set of acceptance criteria. Omitting this step or creating the list without attention to detail can cause a lot of problems and misunderstandings. The team won’t be able to predict all the unwritten assumptions that the client had in mind, which can result in delivering features that don’t work the way they should.
Final thoughts
A bit of experience is a must to write adequate project acceptance criteria. Knowing what went wrong in the past when similar situations occurred allows software development teams to draw conclusions and protect future projects from potential future misconceptions or malfunctions. That leads to budget optimization and higher client satisfaction. It also allows the teams to meet their estimated deadlines and provide higher-quality solutions.
At G-Group.dev, we’ve been working this way from day one. For 15 years on the market, our main goal was to help organizations establish a robust online presence. Based on acceptance criteria for each project, we could deliver exquisite software that met the requirements and was in tune with the business strategies of companies that worked with us. Do you want to join them? Reach out to us and let’s discuss our potential collaboration.
