Managing UAT in continuous delivery cycles

Testing is a Development Team activity. If a Product Owner is performing UAT then he or she is also functioning as a Development Team member.

At the moment your Definition of Done is not being achieved since UAT is deferred until after the Sprint.

If there is a bottleneck around any development activity, such as testing, then other team members should assist with that activity. A Development Team should be cross-functional and collaborative...skill silos lead to bottlenecks and waste.

Thanks for the reply, Ian.

I believe out definition of done is being achieved, as we fully test each feature as it's developed, including UAT (The PO being our designated "user"), and we have a member of the development team who completes manual testing, and an automation specialist who automates all of the tests.

The issues as I can see it lies in the testing required for a deployment. Our automation suite is constantly running, checking for regressions as we develop. We also need to complete UAT, which should be done by the users, or in this case, the PO. They are checking for regressions, essentially, but focusing more on display issues that the automation can't detect, plus testing it on the supported browser, which our automation can't do (this part is up for debate, and is something that is low risk and isn't really a reason for testing). The actual acceptance of the features has already been done during their development.

We have also taken on board the cross functional aspect of scrum. We all complete testing where possible, our autmation expert as learnt how to write integration tests, and both myself and the other tester can now add tests to the automation suite. It really is just the User testing that is an issue.

So I guess maybe my question is more whether people simply complete UAT on new features in a sprint, and let the automation handle all regression testing, or whether any UAT is done on the entire system each sprint.

Maybe we are hanging onto outdated methods regarding our testing. That's why I'm interested to see what the community has to say.

In Scrum, work that satisfies the Definition of Done should be ready for immediate release. No work should remain undone, whether it be UAT or manual testing, integration or anything else. If you have such a Definition of Done...but work is not ready for release until a subsequent Sprint...then the DoD has not been met.

On the other hand, if your current DoD has been met and the increment is not immediately releasable, then the DoD is inadequate and ought to be improved.

Any work needed to create a releasable increment is development work. This includes any required UAT. In Scrum, those who perform development work are members of the Development Team. End users and/or the Product Owner may be involved, but it is the responsibility of the developers to complete it. If they currently lack the skills to do so then that is the problem that needs to be solved. Development Team members should be cross-functional, and thus able to avoid bottlenecks in the activities needed to satisfy a release-quality DoD.

UAT also causes us problems because it takes 2 resource days for the testing to be completed, and this has to be scheduled. One of the product owners has BAU work that we often have to schedule this testing around, which is one of the reasons we deploy every second sprint.

That implies:
- The UAT work is OWNED by someone, the PO!!
- The PBIs become “Ready for Test” simultaneously near the end of the sprint.


A best practice for UAT may be having the actual software users testing the software to make sure it can handle required tasks in real-world scenarios.

Could the PO or developers represent the real user isolatedly?

How about thinking different?
Let’s refer back to a principle from the Agile Manifesto:
“Business people and developers must work together daily throughout the project.”

I recommend as follows:

Let the business people and developers collaborate to perform UAT.
If more than one developer could represent the real user to perform UAT, the schedule of the PO will not cause the bottleneck.

Perhaps have them performing test of a few smaller stories that are completed part way through the sprint.
A Scrum Master always needs to ensure the team is collaborating on a limited number of stories and completing them before moving on to the next story.

Thanks for the feedback, guys.

In regards to our DoD when it comes to testing, a story only passes if it has been checked by the PO, manual testing performed, then integrated into out automation suite, and the full regression suite run against that story and passed.

I think part of the problem is that certain parts of the business want to hold onto more old fashioned approaches, and these (like UAT) need to be wrapped up more into our process. It's therefore my job as the scrum master to try and convince them otherwise!

Again, thanks for the input, it is appreicated.

Hi,

seems like this thread is solved for Hamish. Nevertheless I'd like to share one thought here.

@Hamish, if you're able to satisfy DoD within 2 sprints, then some of those points may work in your case:
- if sprint is 2 weeks or less, you can make it twice as long (if business accepts the risk)
- if sprint is more than 2 weeks, than remain the current cycle and cut sprint backlog in half

Cheers,
Bartek