UAT – How to handle it in Scrum

UAT (User Acceptance Testing) is an important aspect of software development life cycle. It is a kind of toll gate where actual users test the application and certify that whether application is good to go to production. Hence it is very critical in terms of providing quality product to the customers.

There are few important questions about UAT when team is working in 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 which comes 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, team is expected to deliver 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 team may not have UAT tester as part of the team. So basically, there would be dependency on external team and would not be possible for team to complete the UAT testing within sprint time box. Hence team need to discuss with stake holders and have UAT outside the sprint scope or DoD.

Whether UAT should be part of DoD?

As mentioned in above point, if dedicated UAT tester available with the team then it is ok to have UAT as part of DoD and can have it in scope for 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 spill over of stories.

How to handle UAT along with current sprint stories?

If you have 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, have UAT tester also as one of the owner 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 external team and team does not have any control on that, then there should be an agreement between team and stake holders on how to handle UAT.

The best approach would be to have DoD defined clearly. DoD should not include UAT as part of 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, team can have support stories for UAT in current sprint and can track whatever bugs are coming or whatever support UAT testing team would require with these stories.

Hope this will help you in handling UAT in better way for Agile projects.

One comment

  1. Took me time to read all the comments, but I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commenters here! Its always nice when you can not only be informed, but also entertained! Im sure you had fun writing this article.

Comments are closed.