Define the task the application needs to complete
An acceptance criterion should describe a user's task, the expected outcome and the conditions in which it happens. Avoid closing the work merely because the screens exist. A collection of pages can be designed while the process that motivated the application still depends on manual steps you wanted to remove.
When planning a sports prediction application, I specified that match results should be collected and used to calculate standings. The intention was to avoid entering that information manually. Having an attractive table of matches would not have been enough to demonstrate that this objective had actually been met by the application.
That example shows the difference between a visible feature and a complete task. There is a data source, an update, a calculation rule and a result presented to people. Acceptance needs to follow that sequence and check whether every part contributes to the behaviour originally requested for the project.
In a hypothetical booking application, the task might start with choosing a time and finish with a reservation confirmed for the right people. Seeing the calendar is insufficient. You need to understand whether the time becomes unavailable after booking and whether the saved information matches the choice that was made.
Write these criteria when planning the application before starting to code. If they only emerge at the end, the team may be evaluating a different objective from the one that guided construction. Defining the outcome early lets you request concrete demonstrations instead of debating generally whether everything is ready.
To prepare your next step, explore Building digital products with AI.
Check the data and state after each action
A task is only demonstrated when the information received, stored and displayed matches the defined rule. Compare the previous state with the action's result and reopen the record. The interface may display a confirmation without the operation having produced the expected effect in the system that supports the application being used.
In the booking example, reserve a time with a test account and inspect the reservation from the team's view. Check the date, service and status. Then end the session and sign in again. The aim is to distinguish a persistent result from a temporary update that existed only on the screen.
If calculations are involved, prepare examples whose results you can confirm. A sum, ranking or allocation rule needs known input values. Do not accept merely that the application displays a number. The person validating should be able to explain why that is the correct result for the case being tested.
Observe incomplete updates as well. An external source might omit some fields or be unavailable. Define what the application displays in that situation and how it avoids presenting old information as current. The completion criterion should include an understandable response to failures that matter for the particular process being supported.
The work of testing an automation before handing it to the team helps organise this evidence. Bring together the prepared case, expected outcome and observed evidence. If the exercise used simulated data, identify that scope so a simulation does not become a claimed confirmation of the real integration.
Validate who can perform each part of the work
Acceptance should include the roles that will use the application and the actions each can perform. Check permitted and rejected access with accounts suited to the exercise. A demonstration using only the administrator account does not prove the team will have the right permissions when people begin their normal work.
In the hypothetical example, the person assisting customers may need to view bookings while someone else manages availability. If both receive full access merely to make the demonstration run smoothly, an operational decision remains unresolved. Test accounts should represent the responsibilities that will exist during ordinary use of the application.
It also matters where the project is held and who controls the services. I have had to correct a repository created in my personal account when the intention was to keep it in the company's account. The code existed, but the team did not have the intended continuity through its own access.
This care does not require every project to be handed over in exactly the same way. It requires the organisation to know who controls code, data and operation under the chosen model. Handover remains incomplete when only the builder can explain where the work is held or publish a necessary correction.
That is why defining who approves what when working with an external team also forms part of acceptance. Content decisions and technical decisions may belong to different people. Identify who confirms each dimension without turning a technical test into business approval that nobody has actually given for the result.
Distinguish the tested environment from the delivered one
Verify the result under the conditions in which it will be available, with the intended configuration and access. A local test can demonstrate part of the work without confirming the published service. Record the environment used and dependencies that still need configuration or validation before the team can use the application.
An application may work on its creator's computer because files or settings exist there that have not been prepared elsewhere. Handover evidence should reveal those dependencies. The recipient needs to know what is available, what must be configured and who is responsible for doing that work before ordinary use begins.
Integrations deserve a similar distinction. The system may show a “sent” message because the test simulated a service's response. That is useful for checking internal behaviour, but it does not confirm receipt by a real person. When such confirmation forms part of the objective, an authorised exercise and appropriate verification are necessary.
Avoid resolving this difference by sending messages or creating real operations without control. Prepare agreed recipients, data and test conditions. Acceptance should produce evidence without introducing improper work into business operations. The exercise plan needs to clarify which effects are permitted and how the team will recognise them when they happen.
After the application becomes available, confirm essential journeys again from a normal user session. Also check what happens on a device relevant to the team, such as the phone used by someone making bookings away from the office. Completion should match the intended usage context, beyond the most convenient demonstration.
Close with explicit outstanding work and clear responsibility
Closure should state what was accepted, which evidence supports it and which outstanding items have an owner and next step. Distinguish a future improvement from a failure that prevents the main objective. The team can decide more clearly when it receives a concrete status instead of a generic message announcing completion.
A short report can connect every requirement to its test and result. If booking works but access recovery still fails, those two facts need to appear separately. The agent should not present the average state of the work as success while a condition necessary for use remains unmet in the application.
Some differences can be accepted consciously. An additional export may wait for a later phase if it was unnecessary for the agreed objective. Losing bookings or exposing another person's data changes the conditions of use. Priority should follow the impact on the process and the decisions of those responsible for it.
Also record who handles failures after handover and where the information needed to investigate them is kept. That includes the change history and operating instructions appropriate to the project's scope. Users do not need to memorise how the application was built, but should know how to get help and maintain continuity.
I would consider the work complete when an authorised person can perform the agreed tasks, results have been checked and subsequent responsibilities are clear. AI can help organise all that evidence. The phrase “I have finished” becomes useful when accompanied by proof that lets you accept the application under the agreed conditions.