When to consider a story done?

Is it ok to mark the stories done if the stories are not tested by a QA yet.

Done should mean fit for release. If your suggestion was OK, why would you need quality assurance in the first place?

Now the team says, lets mark the stories done if they are developed and if PO okays the demo session in order to avoid spillover. Is it ok to mark the stories done if the stories are not tested by a QA yet.

Does all these stories meet the acceptance criteria defined ? Is testing included in your DOD ? Does your increment meet your DOD ?

We can take a look at this from a few perspectives.

First, with respect to the pillars and values of Scrum.

When the team says that work is done, that means they have met the agreed upon Definition of Done. Having a clear and agreed upon Definition of Done is designed to promote transparency, which is one of three pillars of Scrum (along with inspection and adaptation). If you call work done that is not done, it seems like you are not being transparent with the team and with the stakeholders. When you don't have transparency, it becomes much harder to inspect your work and your way of working. And when you can't take a good look at the work you've done and how you have done it, it becomes much harder to make informed decisions about how to change and improve. Empirical process control collapses - you are no longer making decisions based on what was actually experienced by the team.

Scrum is also centered around five values - commitment, courage, focus, openness, and respect. There are several relationships between these values and the pillars of Scrum. Part of openness is about sharing the challenges that have arisen. Based on your description, you've had some ongoing challenges - work from the previous Sprint was not tested, issues arose from production that needed immediate attention, and the team didn't have the ability to focus on the planned work for the Sprint and the commitment to the Sprint Goal. Calling undone work as done is not being open about the fact that the team encountered challenges that prevented them from getting work to the agreed upon state of done. It is hard for the team to stand up and admit to problems and challenges, but this is where courage and respect come in - the team needs the courage to accept that there were problems, a commitment to continuous improvement, and there needs to be respect from and towards all involved (in and out of the team), especially in challenging times.

I'd also point out that the purpose of a Sprint is not to get work done. It is to achieve a Sprint Goal. There should be no benefit or reward in getting work "done" or having work not in a "done" state. The primary purpose of the Sprint Goal is to give the team the ability to prioritize work and focus on what is most valuable to the stakeholders. The goal should not be to complete a set of work, but to deliver something that is valuable. Focusing on committing to and meeting the Sprint Goal instead of finishing a body of work can have a huge impact on the team and is worth looking at.

So, I would ask you: Why would you want to call work done when it's not really done? What benefit is this to the team, to the organization, or to stakeholders?