2017 Scrum guide vs 2020 guide

The 2017 scrum guide says that 3-9 can be considered an optimal size for developer teams

The suggested range of "10 or fewer people" in the 2020 Guide refers to the Scrum Team, not Development Team. A Scrum Team must include one Scrum Master, one Product Owner, and Developers.

why should the sprint goal be combined as a part of the sprint backlog? 

Transparency. The commitment is made plain within the artifact.

The 2017 scrum guide says that 3-9 can be considered an optimal size for developer teams and less than 3 would lead to lack of interaction and more than 9 would mean a lot of coordination.

Having worked on both ends of the limits where I have worked with developer teams with 2 developers and teams with as much as 11 developers, I have practically undergone these complications. 

So, when I read the new 2020 guide which says the team size can be 10 or less, I am a little confused by this change? why isn't there a lower limit?

One difference is that the 2017 Scrum Guide described the size of the Development Team (or, in 2020 Scrum Guide terms, the number of Developers) while the 2020 Scrum Guide describes the size of the Scrum Team. Assuming that there aren't people filling any roles, the 2020 Scrum Guide suggests a team of 1 Scrum Master, 1 Product Owner, and up to 8 Developers. Good practices suggest that it is possible for the Scrum Master and/or Product Owner to also be a Developer, but that the Scrum Master and Product Owner should not be the same person.

It's also important to note that the 2020 Scrum Guide says that a Scrum Team is "typically" 10 or fewer people. It is not a hard rule that a Scrum Team must be 10 or fewer people. You could have a team of 11 or more people and still be following the rules of Scrum. Although as the team grows in size, it may be more difficult to achieve the Scrum Events within their timeboxes, particularly the Daily Scrum and the Sprint Retrospective, depending on how those events are executed.

The lack of a lower limit is somewhat concerning to me, as well. When there are fewer than 3 Developers on the team, the Daily Scrum loses its value. Since the Daily Scrum is for the Developers, it is trivial to synchronize work with 1 or 2 people without a formal event and the structure of the formal event adds wasteful overhead. If you were to drop the Daily Scrum, you would no longer be doing Scrum. Not doing Scrum isn't a bad thing if it means the team is more effective, but the lack of guidance around situations where Scrum may not be suitable doesn't help organizations make informed decisions about using the framework.

I don't know why there isn't a lower limit, but I always suggest approaching a team's way of working with a critical eye. Don't tie yourself to a particular framework and examine if the structure and practices of the framework are working for you. If they aren't, seek out alternatives.

As per the 2017 version the sprint backlog = the product backlog items taken for the sprint + the plan for delivering them. Although it is mentioned that the sprint goal can be met by the implementation of the product backlog items chosen during the sprint, nowhere (as far as I can see) is the sprint goal combined as a part of the sprint backlog.

Whereas the 2020 guide says the sprint backlog = sprint goal + the product backlog items taken for the sprint + the plan for delivering them. Why is this so? why should the sprint goal be combined as a part of the sprint backlog? 

Just to get my understanding right, is the sprint goal achieved only after implementing all the product backlog items taken for the sprint? No, because the sprint backlog is an emerging list and changes over the sprint. when a developer understands that they are not able to complete a sprint backlog item within the sprint duration they can still re-estimate them and push it back to the PB (under the discretion of the PO). That doesn't mean the sprint goal is not achieved right?

The Sprint Goal should be part of the Sprint Backlog because it helps with focus. This change was part of the 2020 revision, in order to put the Sprint Goal inside of one of the Scrum Artifacts. The Product Goal, which was added in the 2020 revision, lives as part of the Product Backlog. This change was designed to add clarity. I believe that it also helps the team focus.

The understanding that the Sprint Goal is achieved only after implementing all of the Product Backlog Items for the Sprint is not correct, though. In the 2017 version, there was a possible relationship between the selected Product Backlog Items and the Sprint Goal ("Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog" and "selected Product Backlog items deliver one coherent function, which can be the Sprint Goal"), these statements were removed in the 2020 update. The Sprint Goal is now, more broadly, "the single objective for the Sprint".

In cases where the Sprint Goal is connected to the Product Backlog Items selected for the Sprint, I encourage teams to consider aligning the Sprint Goal to a fraction (usually 60-75%, unless there's specific historical data regarding capacity and unplanned work) of the selected Product Backlog Items. Even though it's not required, I do think that it is a good idea to make the Sprint Goal about helping external stakeholders realize some value, but this is no longer mandated by the Scrum framework and there may be good reasons to establish a Sprint Goal that helps the Scrum Team rather than an external stakeholder.

Sai Krishna Sundar is right. The recommended scrum team size changed from "5-11 (3-9 Development team members + SM + PO)" to "10 or less". So many blogs were written about the differences between words like self-organizing vs. self-managing, about servant leader vs. true leader. But no one writes about having one person less in the scrum team.   If the argument is, that it is only a recommendation then I would ask back, why was it changed in the first place? Just wondering. Thanks for sharing your thoughts on this

I guess it will be better for the next version of the SG to remove even suggested numbers of staffs in the Scrum Team. For some teams, it is enough to have even 3 members, for some it is not enough to have even 15 members. 

Or to add info that if there are more than 20 members it is better to divide the team

Hi All . Good Points made by all. Just continuing with what Thomas Owens as said for the upper limit(10), for the lower limit we can think a team size of 3 for developers and 4 for Scrum team. Because with 2 developers, you can't generate much value and no need for such events. With 3, it adds some value to have these events. Similarly with scrum team size, 4 could be the lower limit, because of the aforementioned reason. The only difference is that in this case is the 3rd developer can be a developer cum SM(wearing 2 hats and you dont normally see a developer cum PO - so ignored this option) and then 4th person would be the PO. So Scrum team lower limit would be a 4 and upper limit would be 10.  Probably while writing the guide they would have felt this as superfluous statement. So may be they left it . This is my view

Hello

The Scrum Guide, which I found here is just a few pages and does not contain all the information. Where can I find a complete the ultimate guide?

The official site is https://scrumguides.org

Yes, that is what I checked out - https://scrumguides.org/scrum-guide.html - it contains minimum information. Where to find the ultimate guide?

You found it, that is the ultimate guide. Scrum is minimally prescriptive.

Books by Scrum.org rrainers are listed here:

https://www.scrum.org/resources/books-our-professional-scrum-trainers