How many Definitions of Done does Scrum need?

Scrum is minimally prescriptive. You can have as many Definitions of Done as you like, and at many levels, but there must be a Definition of Done that asserts the quality of the Increment and which provides transparency over this.

I once inherited a team that had multiple Definitions of Done (DoD) as a workaround for organizational constraints they didn’t know how to address. For example, they needed sign-offs from Legal and Security, which couldn’t be completed within a Sprint. UAT was another common issue.

The result? Transparency was lost. The Increment wasn’t truly "done" and issues discovered late in the release cycle came back to haunt us, often with a higher cost to fix. The cost of undone work became the clearest lesson: one true DoD that reflects a usable, fit-for-purpose Increment is the only sustainable path.

If a team feels the need for more than one DoD, that’s not a reason to change Scrum or bend The Rules of the Game. It’s a signal that the organization needs to change to support Scrum and business agility, not the other way around. Though isn't it often easier to change Scrum?

Given your use of “Expand”, I assume you are referencing the recently released SG Expansion Pack from Jeff, John and Ralph. My comments on predicated on this assumption. 

I would say that the Definition of Output Done is really just the Definition of Done that we know and love as a commitment to the Increment. They have given it an expanded name and some new language in the definition, but for the most part it feels the same to me (commitment to quality/tech standards for the whole increment).

Definition of Outcome Done is the new one introduced. Something that looks beyond the outputs of the Sprint to validate if outcomes or hypothesized benefits were actually achieved. I don’t think this takes away from the Scrum framework in any way. It doesn’t change the DoD or it’s purpose, it is complimentary practice that supports evidence based product management. 

I will admit I am still deciding how I feel about the expansion pack overall. Scrum is purposely incomplete so we can bring in whatever complimentary practices make sense for our context. This expansion pack feels like a collection of those. Something similar to the Scrum.org Learning Series content (which is already doing a great job expanding on Scrum concepts). 

In Scrum, you only need one Definition of Done (DoD) per team.

Single DoD per Scrum Team:

The Scrum Guide explicitly states that the Definition of Done is a shared understanding across the Scrum Team of what it means for work to be complete. It applies to all Product Backlog Items.

Thanks all. I also inherited a team with multiple DoDs, it enabled them to claim story points without the "increment" being usable or valuable. One of the first questions I now ask of clients is "How much time and work is there between your definition of done, and code being in production doing it's job?". It's a finger-in-the-air measure of undone work, or immaturity. And they usually don't like me asking.
Re the "Expansion Pack", I read the Definition of Outcome Done as redundant with a well written Product Goal, and the Definition of Output Done as a reduced version of DoD, enabling teams to say they've "done an increment" regardless of the increment being of any value. 
I agree with Chris; it's easier to change Scrum than address lack of efficacy in your system.

it enabled them to claim story points without the "increment" being usable or valuable

When I see teams 'claim' story points for undone work, they are a but shocked when I tell them their velocity is ZERO.

One of the first questions I now ask of clients is "How much time and work is there between your definition of done, and code being in production doing it's job?". It's a finger-in-the-air measure of undone work, or immaturity. And they usually don't like me asking.

They probably have no score card at all for technical debt. This can be embarrassing for people who otherwise play by the numbers, so they throw up the defense shields.

Rather than asking "how much", consider asking how this remaining work is being accounted for and managed. Wonder about it. Expect dismissive or patronising responses about how things work in the company. No matter: just start a train of thought about due diligence and accountability. Any numbers can come later.

Not so late to the party I hope, but I want to shed some light on the DoD as a commitment in scrum, and also address the concept of « DoD of outcomes » introduced in SGEP.

First, on the standard DoD, there should be only one per product. This, especially, holds true if you have multiple teams working on the same product. 
How ? The best way to promote and keep transparency and alignement, within and outside the teams, is to have a single DoD per product so that integrated work and increment have one source of quality checks.
One thing to keep in mind though is that the unique DoD may have some quality checks that may concern only one team. And even in that case, those checks should remain part of the unique  shared DoD to ensure everyone has the same understanding of what "Done" means.

About the DoD of outcomes, newly suggested in the SG expansion pack, it concerns validating the outcome of the sprint, following the running of the experiment (sprint) and delivering the output (increment). It’s truly an inspection of the increment in regards to hypothesis taken that needs to be validated in order to see the kind of value it creates and thus helping formulate new hypothesis about future goals. Given that and in my humble opinion it should not be called DoD, because it creates the confusion that everything in it must be respected and valid, but it's not the case, it is an evaluation of the experiment. In my perspective, it does expand on scrum by going into details and being more prescriptive and obvious let’s say, and it does not contradict scrum. However, it should not be called DoD as its purpose is different. I would suggest calling it simply Spring Goal Verification.

As a Product Owner, I need one definition of Done. Done for my team means it passed Quality Assurance testing and then received my approval. We will take that completed story to the users during sprint review who may wish to further refine/improve the work. Most often, they will play with the functionality in our Demo environment and then offer feedback after a period of time. In some instances, they may not have feedback until after using it in the live application. Our 2 week sprints allow for adjustments to meet user needs.

When a different team started work on this project, they had Done, Done Done, Done Done Done. This was confusing, and we never saw actual functionality developed or presented. When pressed for what the 3 definitions meant, it was clear the definition was a constantly changing interpretation. Thus my team wanted one definition of Done.

For the examples of needing sign off by other groups before something is considered done, I would wonder if the AC's were aligning to the outcomes expected or if there were dedicated quality assurance testers (whose job is to understand user workflows) or if the story/stories was/were too big. But I can also understand that some applications may be very complicated to the point that only the end users can truly validate.