UAT Testing

You basically have 2 choices:

1. You treat it as "release to production" and the Product Owner contacts the users to test the functionality in UAT.



2. You treat it as part of development. Then it should be in Definition of Done, and  it should be part of the Product Backlog Item's flow to "Done".



I'll,argue the second is the "better" option: by getting these testers to "join" the team, and calling the Developers, they are part of the workflow, and responsible for the value and getting the item to "Done". Their work should be part of the Definition of Done.



Often organizations choose option 1, because it is easier. But it is not correct: would you realease to production if the UAT testing has not been done? No, of course not. Well, in that case the UAT testing is part of the workflow, and should be in the Definition of Done.

I agree with Mario, UAT should be done every Sprint if necessary, and be part of the Definition of Done. If UAT is blocking the release of value by having to wait for someone outside of the Scrum Team, something has to change. If the Scrum Team has done all they can do to resolve the external dependency, perhaps it is an impediment the Scrum Master should help with to bring change into the organization.

I think there's quite a bit going on here, in a few different layers.

I'd disagree with the others on where UAT goes. Since the Scrum Team cannot control when the users who are performing UAT start their process, end their process, or deliver their feedback, putting the completion of the UAT within the Definition of Done doesn't make sense to me. The Scrum Team's Definition of Done should include the things that the team can do to enable the UAT to happen and increase the chances of a successful UAT, but Done work is what should be put through UAT.

I'd also challenge the need to finish UAT before putting a change in production. UAT should be a gate for a user to use functionality, not the functionality being available. In software, you can use feature flags (as one example) to control the visibility or accessibility of changes. In an article, Pete Hodgson writes about different categories of toggles and how they are controlled. This lets you separate putting the implementation of a feature into an environment with when users get to use that feature, allowing them to enable a feature flag and perform UAT in a testing environment and waiting until the feature is acceptable before enabling it in production.

The need to perform UAT is something that should be left up to the users. Communicating product changes to stakeholders is most closely related to the role of the Product Owner in Scrum, but I don't think you can say that the person with the Product Owner role is always going to be the one working with the people performing UAT. Like many things, the Product Owner may delegate it to others and your organization may have people, like account managers or a customer success team, who are more closely related to helping the customers and users through product changes.

User Acceptance Testing is not mentioned anywhere in the Scrum Guide so there is nothing to provide guidance on to do it.  The word "release" is only used twice and that is in the section that describes the Increment. Here are the two statements:

The Sprint Review should never be considered a gate to releasing value.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Notice that neither of those say anything about being released to Production.  In fact, no where in the Scrum Guide are there any mentions of releasing something for production use. Most references are to providing the increment to the stakeholders.  It is up to the people implementing Scrum to decide what that means.

If your organization requires that User Acceptance Testing be done before releasing to Production, maybe you should consider that releasing to a User Acceptance Testing environment is the goal of your Sprint.  It slows down the feedback mechanisms but it could be the best you can do.  I have worked with that organizations that did it this way.  It was not ideal but it was productive.  In the end, we always moved towards the solution of involving stakeholders directly in the Sprints and Sprint Reviews.

Many a times the user stories requires UAT testing

Are there any exceptions? Would a user story ever be Done if its implementation was not acceptable to those users?

before it is pushed into production.

I'd suggest that in lean and agile practice work is never pushed anywhere, it is pulled in response to a clear demand signal.  

Now if the UAT users are outside the Scrum Team. 

If that's the case, we have an issue right there. The team is incapable of producing a Done piece of work that is of immediately usable quality and of assuring its own empirical outcomes.

Now the question is...

Let's take care not to predicate any further questions on potentially flawed assumptions. There are questions enough already.

• Does the Definition of Done actually include the UAT that is needed?
• If it does, why is work being pushed elsewhere for that UAT to happen?
• Why can't the team do UAT and meet the DoD for themselves, each and every Sprint?

Thanks a lot for sharing various views .

As per my experience in real time ,It is not neccessary to have UAT users always within the scrum team and it depends purely on the context and type of the work the team does .

When you have dependency with UAT users, I dont think it is in purview of the scrum team to make it as a part of DOD.  If we talk about scrum guide, it says UAT also has to be done in the same sprint  but in many cases that feasibility will not be there .

I felt the release ready stories can have DOD that UAT has to be completed  and can be released. 

Any thought ?

According to my practical life, it is not always necessary to have UAT users in the scrum team, and it is absolutely dependent on the circumstances.

The SM coaches the team to become more self-managing and cross-functional. In becoming cross-functional, the team is:

• Absorbing authorities and skills that currently exist outside the team so they don't have to hand off work and get get to DONE by themselves in the sprint
• Absorbing people that currently exist outside the team for the same reason as above, as long as it doesn't grow the team too large.
• Working with outside dependent people to ensure delays of handoffs are minimized or eliminated to create virtually no obstacle in getting to DONE during the sprint. The people outside the team should be dedicated to the team's work so they are readily available.
• Aware of this situation, and working with the organization's leadership to make the effects transparent.

One way to make it transparent is to create a kanban each sprint to serve as the sprint backlog. Put a column for any outside group you are dependent upon, and ensure that the item aging and cycle time of that state (column) of work is recorded and shown during the sprint review to stakeholders.

That way, your sprint review sounds like this: "We finished three items, we selected five, but were unable to finish the last two. As you can see, the turnaround time on item 4 and 5 was three days, so by the time we got them back. there was not enough time to continue the work and complete it to meet the DoD by the end of the sprint."

Sometimes teams don't realize that the sprint review isn't just a demo of what is done, but also a an opportunity to share with the stakeholders how the environment is impacting the team's ability to work. 

Just remember this word: diplomacy.