UAT (User Acceptance Testing) is an important aspect of the software development life cycle. It is a kind of toll gate where actual users test the application and certify whether the application is good to go to production. Hence it is very critical in terms of providing a quality product to the customers.
There are a few important questions about UAT when the team is working in an Agile environment.
1. Whether UAT should be done inside the sprint?
2. Whether UAT should be part of DoD?
3. How to handle UAT along with current sprint stories?
4. How to plan stories when UAT is happening outside the sprint?
5. How to handle changes that come to post UAT? or how to handle UAT defects?
I will try to answer these questions one by one based on my experience.
Whether UAT should be done inside the sprint?
As per definition, the team is expected to deliver a shippable product each sprint, but practically it does not happen. Teams would be delivering to production may be monthly or quarterly. Also, there is a possibility that UAT is done by some external team of users, and the team may not have a UAT tester as part of the team. So basically, there would be a dependency on the external team, and would not be possible for the team to complete the UAT testing within the sprint time box. Hence team needs to discuss with stakeholders and have UAT outside the sprint scope or DoD.
Whether UAT should be part of DoD?
As mentioned in the above point, if a dedicated UAT tester is available with the team then it is ok to have UAT as part of DoD and can have it in scope for the sprint but usually, that is not the case, then having it outside of DoD is the only option else team would not be able to meet DoD and it would cause spillover of stories.
How to handle UAT along with current sprint stories?
If you have a UAT tester available with the team and planning to have UAT as part of DoD, then you should have UAT testing as part of the story as tasks, have estimation done for that task, and have a UAT tester also as one of the owners of the story and mark the story done when all the tasks along with UAT testing tasks are done.
How to plan stories when UAT is happening outside the sprint?
How to handle changes which comes post UAT? or how to handle UAT defects?
When UAT is done by the external team and the team does not have any control over that, then there should be an agreement between the team and stakeholders on how to handle UAT.
The best approach would be to have DoD defined clearly. DoD should not include UAT as part of the completion criteria. Stories would be marked done without UAT also and demoed to PO and stakeholders.
Whenever UAT is happening anytime after the sprint is over, the team can have support stories for UAT in the current sprint and can track whatever bugs are coming or whatever support the UAT testing team would require with these stories.
Hope this will help you in handling UAT in better way for Agile projects.