Do we need to keep the user stories as UNDONE until QA certifies as working correctly

Here the QA is not involved because either the user story is dependent on another US and can't be promoted for testing individually OR by the time development is completed, there will not be enough time for QA to verify. Please let me know is this right way to do it or not ?

Look up the INVEST criteria, which describe a well-formed user story, and consider what the "I" and "T" stand for.

If we don't move to DONE, all the user stories will be carry forwarded to next sprint.

Why isn't any work remaining re-estimated on the Product Backlog, such that it may or may not be planned into subsequent Sprints?

This is new Team started couple of sprints back before I joined. The Team don't have DOD defined and I'm working with team on it.  Not defining DOD is a reason for above situation??

I'd suggest that not defining "Done" is a reason for many problems, many of which your team has not yet even started to uncover. How can the team forecast how much work they can take on in a Sprint, when they don't really know what it takes for that work to be complete?

"Done" can exist at many levels, including what it means for work to be considered "ready" for Sprint Planning in the first place. The seeds of success are first sown in refinement.

Given there are impediments to producing a "Done" releasable increment, as Scrum Master, you might need to help make that situation transparent; and you might need to help the Scrum Team inspect and adapt in order to address the problem.

Defining "Done" sounds like an obvious first step, and as further things emerge from trying to produce an increment that meets this definition, it might be necessary for the team to change its way of working.

For example, this might mean approaching the work in a different way, or ensuring team members have a more effective distribution of skills.

Why is QA outside of the Scrum Team, but needed to have something done?

Scrum Guide says:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment. [...] 

Development Teams have the following characteristics: [...]

• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

Therefore whatever your Development Teams has done is done. There is no outside review that keeps your things away from being done, QA needs to be done within your Development Team.

You say PO does also review and only if he approves it is "done". Is the PO part of the Development Team? If not, he does not influence if something is done. If your DevTeam says they have implemented something to answer the Sprint Backlog Item and it is done, it is done. The POs approval is not needed. If the PO would like something changed, he can set up a new item for the next Sprint.

Having a defined workflow and a Definition of Done will likely help in this situation. Spending some time to understand the life of work, from the inception of the idea to release or deployment would be very helpful, and value stream mapping could help with this. I think this exercise may reveal some information about the value-add of different activities in the way work is currently structured, as well.

Please let me know is this right way to do it or not ?

@Venkata Naga Aditya Charan, Here's an excerpt from the Scrum Guide (and please don't think I'm throwing the Scrum Guide at you :) )

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review.

So, the short answer to your question is No, and I hope the above explanation gives you clarity.

Now, based on what you learnt from your previous Sprints, are there any changes that you could incorporate that could help your Scrum Team achieve a "Done" Increment? Perhaps, reducing the scope such that you can develop and test within the timebox of the Sprint?

Hope that helps and gives you something to start with.

I don't see the value in definitions. Either an item is done and is releasable (individually or in integration with others) or it's not. There is no gray area here.

If QA needs to validate every item, then it's not done and you move the item forward to the next sprint.