Is it ok to release an increment that is not done ?

The Scrum Guide has a few relevant statements:

• "Work cannot be considered part of an Increment unless it meets the Definition of Done."
• "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

There are two ways to approach this problem.

First, hold fast to the Definition of Done. If the work is so important and so valuable to stakeholders, it would be an interesting conversation to understand why it wasn't considered to be more important during the Sprint. If the team got other work Done, why did they choose to do that work over this work? If there are any problems or misunderstandings with the importance or value behind Product Backlog Items, working through those misunderstandings would be helpful to ensure that the team works on the most important things in future Sprints. Holding the Definition of Done can also ensure that no one - team members or stakeholders - can short-change quality in future Sprints.

Second, examine your Definition of Done. If the stakeholders are fine with accepting the work without the relevant documentation in place, why is the documentation part of the Definition of Done? It could be worth asking if the documentation is necessary at all. If the Definition of Done includes unnecessary work, it would make the process leaner to remove that work. The team can focus their time and energy on more valuable work.

One thing that I would not do is release the work in an undone state. Although I disagree with a prohibition on showing undone work in the Sprint Review, I do agree that undone work shouldn't be released. Releasing undone work jeopardizes quality and could lead to other types of undone work being released. In this case, it's documentation. But once people realize they can short-circuit the process, what would be next? Releasing untested work? Releasing defective work? Unless you're deciding to revise the Definition of Done, I wouldn't recommend putting the quality of the product at stake.

I think if the stakeholders really want that pbi in their hands immediately (they want that value asap), and they accept the effects of not complete documentation, I do not think any PO or SM can say, "we cannot release as we do not satisfy our DoD yet". 

In Scrum the Developers are 100% accountable for quality, and thus for ensuring that the Definition of Done is met. They have to be, because they are the ones doing the work, and if quality was to be cut they are the ones who would know about it.

The flip side of this is that they must be respected, so when they say "no" it means no. The Developers are not obliged to make a darned thing available for release if they are unhappy with the quality. Nobody else can make that decision or force them to incur technical debt. It isn't a gated decision either. Once the Developers are happy something is Done and usable, the imperative is to release it and gain empirical feedback.

Any comments on the below approach ?

• PO has the final say for the increment release and if that pbi is ctirical to stakeholders, she can make a decision to release it although DoD is not met (documentation in this case)
• But is that ok ? This is sure not ok but we are just trying to survive in a very hursh market place and PO can act in that direction
• What to do as a Scrum Master ? We should make sure that this case is an exception and and should not be an example for future. May be we can have an discussion around DoD and review it to meet product's and market condition's needs. Also, if that pbi is ctirical, why did the team make this item "done" ? Where is the missing point, is it in the value proposition of PO or team's perception ? We also can investigate this points with our team.  

Any comments on the below approach ?

• PO has the final say for the increment release and if that pbi is ctirical to stakeholders, she can make a decision to release it although DoD is not met (documentation in this case)
• But is that ok ? This is sure not ok but we are just trying to survive in a very hursh market place and PO can act in that direction
• What to do as a Scrum Master ? We should make sure that this case is an exception and and should not be an example for future. May be we can have an discussion around DoD and review it to meet product's and market condition's needs. Also, if that pbi is ctirical, why did the team make this item "done" ? Where is the missing point, is it in the value proposition of PO or team's perception ? We also can investigate this points with our team.

Releasing not-Done work is incredibly risky. The Definition of Done is a gate to release while maintaining the system's quality. Once you allow not-Done work to go through that gate, you have set a precedent that a stakeholder can make demands that any not-Done work can go through that gate. And at that point, the team's ability to ensure the product's quality in the face of stakeholder demands is greatly diminished.

What you are dealing with is a decision to release with technical debt.  Yes, documentation can be considered technical debt, especially if it is a condition of "done" on the Definition of Done.  

As a scrum master, what do you do ?

Initially, absolutely nothing.  This is a decision that is made by the Developers (since they are responsible for the quality of the work done and making sure that there is an increment created by meeting the Definition of Done) and the Product Owner (since they are responsible for all decisions made about the product and for maximizing the work that is going to be done). As a Scrum Master, you make it clear that you are not involved in the decision. 

After a decision is made, as a Scrum Master, it would be useful to bring this up during the Sprint Review.  Since you are an equal participant in that event, having the Scrum Team discuss the way this occurred and how it was handled would be a good thing so that they can learn from the experience. 

BTW, I am pretty sure I have seen this scenario posted here before, almost word for word.  Was this found in a online test or study guide? 

No, it is not recommended to release an increment that is not "Done" according to the Definition of Done (DoD) in Scrum. Releasing an incomplete increment can introduce risks such as technical debt, bugs, or user confusion due to missing functionality or documentation. The purpose of the DoD is to ensure quality and readiness for release. However, if stakeholders are pushing for a release, it's essential to provide transparency about the risks and incomplete aspects, allowing them to make an informed decision. As a Scrum Master, your role is to facilitate this discussion and help the team and stakeholders understand the consequences, but ultimately the Product Owner owns the release decision.

• Transparency:
  Ensure the stakeholders and team members agree on the implications (if any) of releasing without the required documentation.
• PO Leadership:
  Remind the Product Owner (PO) that they are responsible for guiding release decisions and ensuring stakeholder expectations align with the quality of what is delivered.
• Dialogue and Continuous Improvement:
  Facilitate a conversation around modifying the DoD, but not as a knee-jerk reaction to stakeholder pressure. Help the team to reflect in the retrospective and adjust if necessary to ensure that the DoD is clear about which documentation is required (if any) in order for each PBI to be declared "Done".
• Scrum Principles:
  As a Scrum Master, it's essential to help the team members uphold their own working agreements (I'll presume in this case, *practicing Scrum* is one of their working agreements). While flexibility is necessary, remind the team and stakeholders that releasing incomplete work sets a risky precedent. Emphasize that "Done" means meeting all agreed criteria and compromising this will affect future releases.

Important end note: I don't know what is meant in your question by "required documentation" — who requires it? what are the consequences of NOT doing it? So, in my responses above, I've assumed there's widespread agreement that this "required documentation" is valuable, important, useful.

But there's always the possibility that it's a total waste of time — a bureaucratic habit that nobody questions. If that's a possibility, then perhaps host a retrospective to get to the bottom of it. I offer a free facilitation guide for a workshop that helps teams and stakeholders figure out which documentation is valuable, and which is bureaucratic waste. Feel free to use this for your next retrospective: https://scrum.works/articles/2018/11/The-Art-of-Agile-Product-Documentation/