Understanding "Definitions of ..."

The Scrum guide advises having a Working for a Definition of Done. It also hints that a Definition of Ready might be useful. New teams occasionally struggle with defining these agreements appropriately. Here is a small summary of what these definitions imply:

Relationships between DoR, Sprint and DoD

Definition of Done

The simplest "Definition of Done" is "No more work to do.", in the sense that "The customer has the final product." For some teams just starting the agile journey, it is not possible to achieve this within the Sprint. They might rely on a manual User Acceptance Test done by a testing department, a deployment done by SysOps and many other things.
Their DoD excludes all the work from the sprint which will not be done by the team.

The ideal DoD

"Done" does not exclude anything, so the DoD would imply to include everything. This usually is the case for teams using Continuous Deployment, delivering complete value to the customer many times a day.
In this situation, a formal DoD becomes unnecessary - but many organizational impediments need to be removed until then.

Definition of Ready

The simplest "Definition of Ready" is "We can start to work.", in the sense that "We have an idea to work with." Some teams still feel insecure working with little or no upfront planning and/or analysis, so they would not achieve getting from idea to solution within one Sprint. They might rely on (big) upfront planning, design and analysis, in the worst case on a full specification document. That, for example, would be the case when only "developers" transition to Scrum, without forming a cross-functional team. 

The ideal DoR

"Ready" is reached as soon as an idea comes up, so the DoR would imply to not require any upfront work at all. Teams need to have a firm grasp on their product, technology and a high customer centric mindset to reach this state.
In this situation, a formal DoR becomes unnecessary, just like a DoD.

Sprint Work

Sprint work includes every work that is not done "outside the Sprint". Everything included by the DoD that was not included in the DoR creates the bracket we call "Sprint". Based on Scrum's definition of a Sprint, this should be all relevant work: Scrum does not account for "pre-Sprint" or "post-Sprint" work.

The ideal Sprint

With this understanding, it becomes obvious that the larger the amount of "undone work" (i.e. DoR work or post-DoD work), the less impact the Sprint has on overall product success.

A large DoR or a strictly limited DoD imply that significant amounts of development work is actually done outside the Sprint - making Sprints an illusion of control!

Conclusion

When first experimenting with Scrum, it's a good idea to make DoD and DoR explicit. This will help the team understand the impediments towards successful end to end delivery of customer value. 
Any limitations imposed on the DoD should be put under scrutiny - as should any items in the DoR.

When looking for ways to optimize your Scrum, look at the size of your Definitions: the DoR should completely disappear, and the DoD should be unconditionally reduced to "Done".