Challanges to perform UAT in Scrum

Thanks Karthik.

From what I understand from your feedback is: the definition of done should include all the test cases that if passed, would mean the product increment is complete (releasable). And the demo with business stakeholders (Sprint Review) would provide the opportunity to seek feedback on the produced increment.

Now, my question here would be:

(a) Sprint Review would occur after the product increment is ready for demo. At this point, the development is done and the team presents demo on the completed work. So, using this meeting as the point to receive feedback from the actual users of the product/software seem late to me. Of course, the PO is the bridge between business and development team but can he/she alone sign-off the completeness of the increment on behalf of the business?

(b) Since it would sound unreasonable to propose the actual business users of the product to be involved as part of development team to perform the UAT, would this be performed without them (based on the criteria captured in the acceptance criteria and definition of done)? If yes, I see another constraint here as mentioned in my earlier post. The development team wouldn't have the broader access in most organization to perform broader tests. How is this constraint dealt?

I know there might be different strategies to deal with it. I heard from some agile coaches that in few projects that they worked, UAT was not considered as a separate gate to declare product increment as done. While others stated, the Sprint was split to accommodate that viz. a 4 week Sprint with 3 weeks of development + 1 week of QA (including UAT). A few other prefer to have a separate time after each Sprint to cover UAT.

The reason for my question is to learn what best worked in the real world staying closer to the principles of agile development.

-- Mohit

Thank you Sergio.

Although I didn't exactly get the answer to my question but maybe I don't have to. Seem like there is no "one point" answer to this challenge cos it looks layered. Depending on what layer the problem is hurting the organization or the adaptability of Scrum framework (and how mature the Scrum team is), different teams may apply different strategies.

The definition of done is an indicator the increment is complete and if the resulting increment meets that definition, it should be ready for release. How that definition is defined is unique to each context. And whether the PO or business actually releases the increment after the Sprint or ask for correction/enhancement to it triggers the next cycle of grooming, planning, work and review. Retrospective meeting would a good place to discuss why that occurred and how the definition of done can be adjusted to overcome that gap.

I do not agree with you in one point. Scrum is simple to implement but the problem is this: Scrum is a framework that must be fullfiled with the tools and techniques best fits for the current situation. That´s forgotten and people talk about user stories, story points and things like that when it is no line inside the Scrum Guide about it, The second is people do not understand that Scrum is based into an iterative-incremental process and tried to map what they do in sequential/waterfall/iterative only/incremental only. Iterative-Incremental seems to waterfall-parallel based activites then things must be done in parallel without intervention of somebody. I mean, people take the pieces to do the job (unit test-sit test-uat) as they see the piece is ready in the previous state without asking. Regarding the definition of done is nothing new, it exists from the prehistory of the software. When you write a requirement the acceptance criteria must be write too and it is composed by the objective to be satisfied plus the process to validate it. That´s all is needed. And take into account what I am saying: it is written when you write the requirement. Retrospectives must be done along the process not at the end of the process. That´s a basic principle of continues improvement and that´s a critical success factor to create "self-directing teams" or whatever the prople like to call it.

Thanks Susan. Yes, even I would think it would be necessary that the acceptance test is performed before the increment can be labeled as "Done". Having said that, I don't think Sprint review is the appropriate time to perform that test. The demo is based on what is already done and this meeting is not focused to fetch that acceptance.

I may be wrong though as some organization may find it appropriate to include in Sprint review. So, possible but not ideal.

Thanks Khai.

The reason why I think it is appropriate for end users (who are actual users of the software/product) to perform the acceptance test is because many a times the development will not have that broader access in the environment to perform that broader tests. And I would assume such tests are included in "Definition of Done". Hence, it can be a challenge on how to include the end users during Sprint though.

Having said that, if the organization (read PO, who represents the stakeholders) is okay to accept an increment as done if the development team performed testing is considered enough, then yes, team is not required to focus on something additional.