The fact that people often misunderstand the Scrum framework then implement poor practices is a disheartening reality, but that is a poor argument against an idea. For example, "The Daily Scrum should be removed because people in the field use it as a traditional status meeting." :-/
"any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning" This existing text has been enough for many, but something more could be helpful.
How does a Development Team determine if a PBI can be "Done" within the Sprint? (Remember they choose the items.) They need to have a solid understanding of the item and/or the Product Owner (or customer) will need to have high availability to work with the Development Team. One indicator of this understanding is the Development Team's estimate on the item, since those are still a requirement of Scrum. Depending on the process Acceptance Test Driven Development may be the method used, so those criteria would need to be defined and well understood.
I like the idea of expanding the notion of "Ready" but not sure of the best way to approach it. This is an idea which has merit and deserves critical thought and discussion.
I understand the intents and I understand Specifying to which team one is referring can be a challenge. Mr. Hartman, find all occurrences of "Development Team" in The Scrum Guide and think about how this change would affect it. (*waits quietly*) That creates quite a mess in my opinion. Of course that in and of itself is not enough hopefully provokes thinking in different terms (pun intended).
I do like the notion of changing the "Development" term as you and others have noted. Overall, the idea that the others are a team is too important to drop the term.
Delivery/Production/____ Team is the question in my mind.
+1 for #NoManagement
"The Scrum Master may allow outside observers or participants" defeats the self-organizing intent for the Development Team; it's more traditional command-and-control management. HK disappoints.
As with most other aspects of the framework, it means exactly what it says. Only DT members participate and the SM enforces that rule. It is up to each team to consider permitting observers. Concerns of negatively impacting the effectiveness of the event, especially with less mature DTs, must be considered. All those advocating the SM or PO participating are advocating violating the rules. Give each DT those fifteen minutes to plan the coordinated effort of the day. Excuses (not reasons) for having other individuals participate are indicators of issues that need to be resolved in some other manner.
IMHO "Scrum is a framework" is clear; any other phrase (within, where, etc.) attached to that is additive and not definitive.
Does this undermine the values? Openness?
Agreed, this can be a point of confusion and that "guide" is probably not the best word. The way I learned it was linking back to the Manifesto language in maximizing the amount of work not done.
What is the purpose of the Sprint Goal? "The Sprint Goal is an objective set for the Sprint." It provides Focus. It was a formal inclusion in 2013: "The Sprint Goal creates coherence in the Development Team’s work that would not be present in separate initiatives without a common goal. Note the formal inclusion of a Sprint Goal." Excluding it in a Sprint can have negative affects on productivity. How can the Sprint Goal be decoupled from the Sprint? It sounds like you are advocating a [InsertSomeOtherTimeframeHere] Goal.
I do like the intent of the proposed change since the Sprint Goal may need to be adjusted as the Development Team does its planning toward fulfilling Topic Two.