User Stories for Dev and UAT

I'd start by using a more typical definition of "story".

There's no such thing as a "UAT story" or "Dev story". Stories are informal descriptions of the features and functions of a product. A very common format is a user story, which describes the features and functions from the perspective of a user. But there are other formats, as well. Job stories focus on situations, tasks, and outcomes. Problem stories focus on the problem. Regardless of the format, they are lightweight, informal, and written in an appropriate language to enable communication between stakeholders.

If your workflow involves development, UAT, and production deployment, you don't have stories for these activities. Instead, you would track the state of the story. First, the Scrum Team would develop the story. Once it meets the team's Definition of Done, it will be made available for external stakeholders to perform UAT. Finally, accepted work can be deployed to production.

If the team is estimating stories, and I'd point out that neither estimation nor story points are a part of Scrum, then the team would be estimating their effort to get the story Done. If your Definition of Done ends with ready for UAT, then I would expect the estimate to account for all work to prepare the story for UAT.

I would also hesitate against reopening stories. If you progress a Done story to UAT or production and find a new issue, create a new story to represent the work. In my experience, many Scrum Teams use stories to represent Product Backlog Items. If your story to resolve the issue is a Product Backlog Item, the Product Owner can order it among all the other features to implement and issues to resolve.

When dealing with UAT, I've found that it's best to move UAT outside of the Scrum framework. The Scrum Team is delivering to the UAT environment at least once per Sprint, and sometimes more frequently. The goal should be for UAT to find no issues that would prevent acceptance of the product. The feedback from UAT should be work the team can put on the backlog for future Sprints. If UAT is finding stopping defects, the team should use opportunities, like the Sprint Retrospective, to understand why they are putting a product of unacceptable quality in front of stakeholders and solve those problems

If a Dev story is complete but awaiting UAT, the Dev story can be marked as complete , but cannot be lined up for Production Release.

If it isn't fit for immediate use, it isn't complete. Moreover once a piece of work is complete, the imperative is to put it to use right now, no later than the end of the Sprint in which it was developed, so empirical feedback can be obtained. 

If there is a "line up" for a  "Production Release" after the Sprint then you've got a problem, because additional work of some kind remains, and the increment is not yet Done.

• Stories for development(Dev) 
• Stories for UAT 

Dev and UAT are more like status of the same story and the story can be marked done only after dev and UAT is completed.  Are you not able to move a story through all stages like dev, unit test,UAT and finally Done (ready for production) in the sprint duration of 2 weeks ?

If during UAT Story execution, the UAT testing team found issues, would it mean that we re-open the Dev Story or create a separate story to address issue that has stemmed from the UAT testing. 

Again the story will not be closed if it is in UAT and probably you will close it only when it is UAT complete (and in some cases after moving to production if your sprint ends with a Prod release). If the bug raised during UAT is a major blocker (you need to triage the defect first based on priority,severity,risk) then the Story is not done and should go back to the backlog. The bug can be raised separately and should be marked as a blocker for the story and in the retrospective discuss why this was not captured during unit testing and improve your definition of done

Appreciate the detailed insights all! 
It may happen that the UAT may go out of the two-week sprint as the team performing the UAT is non-dev team, and it may not be possible to impose the tight timeline of completing the UAT within those 2-week sprints.  

I like the approach of opening new story if there are issues found in the UAT and let them flow into the backlog, but then it also defeats the whole notion of "If it isn't fit for immediate use, it isn't complete". Looks like will have to experiment a bit until we have a good structure and cadence set up.  

Thank you! 

I like the approach of opening new story if there are issues found in the UAT and let them flow into the backlog, but then it also defeats the whole notion of "If it isn't fit for immediate use, it isn't complete". Looks like will have to experiment a bit until we have a good structure and cadence set up.

It only breaks the notion "if it isn't fit for immediate use, it isn't complete" if you treat UAT as an inspection activity to find defects. If you are finding defects, especially critical defects that would prevent rolling out what is in UAT to production, the team is not ensuring the quality of the product. If you treat UAT defects as seriously as production defects, you can work toward enhancing your Definition of Done to prevent those defects.