Development team size
For the first question, you've already figured it out. In this case the 3-9 is a recommendation or guideline, but no strict requirement. More important than size is this element:
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
If you need specific skills to get work done, you may need to start out with more than 9 members. Hopefully, over time, you will be able to work on skills-transfer, learning and training to reduce the need for a big team. Until then, you are still doing scrum, just a little handicapped.
The Sprint Planning
The 2011 Scrum guide was the last guide from the top of my mind that still had an explicit part 1 and part 2. Later versions changed that to topic 1 and topic 2. This is to indicate that there is no strict time-based relationship.
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Topic One: What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint...
Topic Two: how will the chosen work get done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint...
Instead of strictly having a 2 part planning event, you could take smaller iterations, picking one PBI from the backlog, working it into the plan before taking the next. In that setup the PO would likely be present the whole Planning Event.
If you'd compare older and newer versions of the Scrum Guide, you'll see that overall Scrum is moving away from strict prescriptions. The Daily Scrum no longer prescribes the 3 questions. Sprint planning doesn't require part 1 and part 2. etc.
Similar questions can be found in the true PSM1 assessment. They can be tricky to answer, not because scrum.org wants to trick you, but because there are a lot of misconceptions about scrum. Barry and Christiaan collected many of these myths in a great blog series.
If I can give you one tip to pass the PSM1 assessment, it's to use these items in order:
Be careful with blogs, opinions, recommendations etc. The Sprint Planning blog you quoted is a great blog for teams starting out and needing some guidance to plan their first sprints. But it's not a strict explanation of all options. It's titled "a typical sprint", not the "the official guide to sprint planning". Also remember that the Scrum Guide has changed over the years, sources older than 2017 can hold inconsistencies.
Note: I'm a Scrum.org Professional Scrum Trainer.
This comment from below the Typical Sprint Planning captures it well:
Alan Larimer • 3 years ago
I had written a more detailed post, but it didn't survive. It is interesting how many "Learn Scrum in X Minutes" and "Scrum Quick Start" and "Scrum Walk Through" articles and videos there are. At seventeen pages The Scrum Guide is hardly an overwhelming read. Counterpoint: it is considered to be written at the Ri (expert) level. For those accustomed to learning processes via step-by-step manuals, a framework can seem to be lacking. With so many "why" and "how" questions left unanswered, a plethora of such instructional material makes the work of understanding a simpler path. Several problems arise as a result.
One of the most common aspects of these attempts is "filling the gaps" for easier understanding. The result being that many take the examples as THE WAY. Thus the flexibility of the framework is lost. Even if it is considered a "best practice" today that my not be the case tomorrow, or that technique might not work for one's own Scrum Team or organization.
Another problem is in poor rephrasing, or even incorrect representation, of the material. Statements such as "the Product Backlog has ... detail, with estimates and acceptance criteria" versus "Product Backlog items have the attributes of a description, order, estimate and value" results in assumptions and inaccuracies.
Take the time to read and apply critical thinking to The Scrum Guide. Go to the sources of the source, read other writings by and watch interviews with its authors. Use other resources with caution and always compare and contrast them to The Scrum Guide. Through individual effort the true understanding of the beautiful power of the framework becomes clear. Then we can have a better tomorrow.