Scrum based on theory of constraints

I'm not too familiar with the theory of constraints and may not be answering your question.

There's a lot that's not explicitly mentioned in the Scrum Guide. It was intentionally intended to be left lightweight, from what I gather.

Sometimes, people start patterns or identify with theories when grasping it.
E.g . don't have it handy, but there are references to how the PDCA can also map into Scrum.

A trip down memory lane --
http://www.scrumguides.org/history.html
https://hbr.org/1986/01/the-new-new-product-development-game
http://agilix.nl/resources/scrum_OOPSLA_95.pdf

Scrum is based upon empirical process control. Teams may decide to use ToC in their Scrum implementation but the framework does not demand it. The delivery of value is the primary measure while constraint optimization is secondary and subservient to this.

Other agile approaches may place a greater emphasis on ToC. Lean-Kanban implementations, for example, may avoid batching work into iterations in favor of continuous flow. However the concomitant lack of sprint goals arguably leads to a reduced focus on product value and business risk.

Thanks - Makes sense to focus my attention to Inspect and Adapt our processes and product as we iterate through our Release cycle rather than looking it at from exploiting the constraints.

Thanks Raj for sharing the OOPSLA document by Ken Schwaber - Great Read!

In my experience you can enhance the flow of a Scrum team's work by exploiting constraints - eg by using WIP limits in a sprint. Scrum is a lightweight framework so external tools such as this can add a lot of value.