Should PO validate/review the user story once it's dev done before assigning to QA?

Much of this depends on the team's process, but there are several things to think about.

Why is there a separation between "dev" and "QA"? How does this align with the fact that "there are no sub-teams" within a Scrum Team?

Why is work being assigned to anyone, much less by the Product Owner? How does this align with the collaborative selection of Product Backlog Items at the Sprint Planning and the fact that the Sprint Backlog is "a plan by and for the Developers"?

Why is the Product Owner required to "validate" and review the work? That seems to be a single person introducing a bottleneck to the team's flow. Does this review often find things? What can be done to reduce the number of errors that are found here and begin to shift knowledge of what the stakeholders need to the whole team?

How can a tester perform UAT? UAT is user acceptance testing. Is your tester a user?

Hi Thomas, thanks for your revert and let me elaborate more here.

First thing, which I missed to mention is UAT environment where the code is deployed for testers to do their testing on user stories developed by the developers. And yes, the sprint backlog is planned by and for the developers and that's what we make sure to adhere to.

In our process once the user story is dev completed, it is deployed in UAT env. and assigned to tester to do testing. Where keeping in mind the acceptance criteria, if a tester finds anything which is not as per AC then raise a bug/issue. 

My only concern here is, as Product Owner knows everything about the user story, so the first question comes - should a PO review/validate the story developed? If so, then when in the sprint? 

In my case, I have worked in multiple agile projects and whenever I have seen PO reviewing the user story and providing early feedback helps the developers to work on them quickly and if anything is missed, can be achieved before sending the user story to tester to test it. 

should a PO review/validate the story developed? If so, then when in the sprint? 

Professional Scrum Developers will collaborate to ensure that work is Done every Sprint, including any testing. I'd suggest that if work is being "assigned" to a "tester", then this may be a warning sign about the effectiveness of that collaboration. 

When the Developers' commitment to a Done increment is satisfied, the Product Owner will not need to "validate" anything about that work. It is usable and may already be in use. Bear in mind that the PO is also a Scrum Team member, and as such will have collaborated during the Sprint as well.

The Sprint Review is a formal opportunity for the team, and any invited stakeholders,  to review the work that has been Done and any work that remains to be Done.

It sounds like a subject for a retrospective to inspect why the need for validation by the PO is there and what can be adapted to remove this gate. 

and also why are story's assigned? This feels like a push mechanism. 

I have to admit, “dev completed” or “dev done” makes me cringe. Until such time that a backlog item is Done, there is no such thing as “dev completed / done”. Testing and validation may uncover defects, which means more work is still needed to get to Done. To quote Yogi Berra - “It ain’t over ‘till it’s over”.

There is no right process or standard rule, but you can always ask yourself “how does this support Transparency, Inspection and Adaptation” and “does this align to the Scrum Values”.

Example: How might Respect be impacted if a PO is providing “early feedback” while Developers are still working the kinks out of the complex problem they are solving?

Example: Regarding “as Product Owner knows everything about the user story” Why is the PO the one who knows everything about the backlog item? Perhaps there is something to reflect on here regarding Transparency and Openness. How might refinement be improved to better communicate and collaborate on product backlog items so the Scrum Team knows everything?

The fact that the Product Owner "knows everything" about the work and hasn't conveyed that information to the rest of the team is, in my opinion, greatly problematic. A user story is a placeholder for a conversation. Especially in cases where there are many competing stakeholder groups, it can be greatly beneficial for the Product Owner to talk to the stakeholders and the Developers to talk to the Product Owner to make sure that the Developers are getting the actual product vision and not the needs of one group of stakeholders. However, through those conversations, the Product Owner should be giving the rest of the team all of the information needed to successfully design, develop, and test the system.

It can be very useful for the Product Owner to be involved in the development. The Product Owner should be available for the team. Sometimes, the questions to ask may not be readily apparent during refinement and would come up when the work is being done. It's also useful for the Product Owner to take the system and review the work being done. However, asking the Product Owner to review each and every story, rather than look at the system as a whole from time to time, introduces a bottleneck in the flow of work that slows the team down. If these reviews are finding significant problems rather than just suggestions or opportunities for improvement, then there are deeper issues to solve.

I think it's important to point out one of W. Edwards Deming's 14 Points:

Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.

Building quality in through the act of refinement and giving the whole team the tools needed to not only build the thing right but also build the right thing is a cornerstone of lean and agile development principles. It needs to be a collaborative process, rather than an inspection after the fact.

I would also make a few other suggestions.

Try to eliminate the subteams. I've found that having specialists is a good thing. Having test specialists can be useful. However, dependence on test specialists to design and execute tests is not valuable. The test specialists should be working with the rest of the team to improve their ability to carry out testing. Having a post-development test process when one is not required (such as for compliance purposes) is wasteful.

Don't assign work. Pull systems are often more efficient than push systems. They also promote collective ownership of the plans and work. They also help the team to maintain a sustainable pace. All of these help to promote agility at the team level.

Dear people, thanks a lot for clarifying the doubts. Lots of pointers I get which will discuss in my team and let the people know about the improvement needed in our process.

Appreciate everybody's response.

Hi Neetu Aggarwal,

I'm not sure what you mean by "QA". There are no "subteams" in SCRUM ;)

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

The Developers accountability (not a role):

• Instilling quality by adhering to a Definition of Done;

Also "assigning to" is not the best phrase. Tasks are not assigned. Although they can be pulled by individual team members, the whole team remains accountable.

The whole team is accountable for creating a valuable, useful Increment every Sprint

Thanks Pawel for your inputs. Appreciate it.