Scrum Reference Card by Michael James and Luke Walter

Last post 03:08 pm September 5, 2019
by Tony Divel
1 reply
Author
Messages
01:59 pm September 5, 2019

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.

 

 

03:08 pm September 5, 2019

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.