Scrum Reference Card by Michael James and Luke Walter
Hi everyone!
To prepare myself for PSPO I exam I was lucky to find this document on Internet. It is very interesting and full of insights and my advice is to read it before trying the test. However going to read the chapter about Sprint Planning Meeting there is a step that is not clear to me: below I write you the whole chapter highlighting the part that is not clear. If someone could help me to understand it better I would be more than happy! Thanks a lot!(https://www.collab.net/sites/default/files/uploads/CollabNet_scrumreferencecard.pdf here is the file with the complete PDF!)
Sprint Planning Meeting
At the beginning of each Sprint, the Product Owner and team hold a
Sprint Planning Meeting to negotiate which Product Backlog Items they
will attempt to convert to working product during the Sprint. The
Product Owner is responsible for declaring which items are the most
important to the business. The Development Team is responsible for
selecting the amount of work they feel they can implement without
accruing technical debt. The team “pulls” work from the Product
Backlog to the Sprint Backlog.
When teams are given complex work that has inherent uncertainty,
they must work together to intuitively gauge how much work to pull
into a Sprint, while learning from previous Sprints. Planning their
hourly capacity and comparing their estimates to actuals makes the
team pretend to be precise and reduces ownership. Unless the work is
truly predictable, they should discard such practices within the first few
Sprints or avoid them altogether. (I don´t get it!)
Until a team has learned how to complete a potentially releasable
product increment each Sprint, it should reduce the amount of
functionality it plans. Failure to change old habits leads to technical
debt and eventual design death, as shown in Figure 15.
If the top of the Product Backlog has not been refined, a portion of the
Planning meeting might be spent doing this.
Toward the end of the Sprint Planning Meeting, the team determines
how it will accomplish the work. For example they may break the
selected items into an initial list of Sprint Tasks.
The maximum allotted time (a.k.a. timebox) for planning a 30-day
Sprint is eight hours, reduced proportionally for a shorter Sprint.
When teams are given complex work that has inherent uncertainty,
they must work together to intuitively gauge how much work to pull
into a Sprint, while learning from previous Sprints. Planning their
hourly capacity and comparing their estimates to actuals makes the
team pretend to be precise and reduces ownership. Unless the work is
truly predictable, they should discard such practices within the first few
Sprints or avoid them altogether. (I don´t get it!)
I haven't taken the PSPO 1 but based on my knowledge of Scrum and Product Management I have a feeling this PDF is not indicative of what you should expect to see on the PSPO1 (someone correct me if I'm wrong here).
It's basically telling you to not use hourly estimates or compare original versus actual to plan how much work the team might fit into a Sprint. There's plenty of techniques that can be used to determine what the team feels they can accomplish in a given Sprint. I'm not going to debate what is 'best' because it's typically specific to the team finding what works for them and continuing to improve their practices if needed.
I'd be more interested in understanding the spirit behind Sprint Planning, why it's important, and what type of outcomes the team should look at achieve and how the Product Owner's role fits into that.