Sprint Planning

Sprint Planning can be hard. However, if the team have conducted Product Backlog refinement and the Sprint Review conscientiously, how likely is it that the event will present significant unknowns and a need for sequenced process?

The unknowns being more or less, still want to understand how the sprint planning starts so that the corresponding PBIs can be selected, as PO has the highest visibility for the end product and its value, though not specifically mentioned here, is the PO most likely to initiate in this event expressing his expectation for the sprint or the sprint goal.

Just some days ago a good presentation on Sprint Planning has been released: 

https://www.scrum.org/resources/effective-sprint-planning

that helpts understand what is going on during Sprint Planning.

Thanks Stefan, as per this video it looks like DT would initiate, selecting the PBs they think can be achieved in the sprint.

Yes, it is the DT's commitment what they will do. Therefore DT should have the lead in selecting work.

Please remember that during Sprint Review you have done, according to the Scrum Guide:

"The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning"

So, depending on what you have achieved during Sprint Review, it might be that PO starts with a quick summary. Still, I would not put it like "PO starts by presenting his Sprint Goal". As the Scrum Guide states "During Sprint Planning the Scrum Team also crafts a Sprint Goal." I therefore would rather say something like:

"PO starts by explaining why the current top entries in the Product Backlog represent the highest value and proposes a draft of a possible Sprint Goal".

If put like that, why not?

Now learning that in sprint review also its expected to discuss the next steps, it does provide clarity that the sprint planning can be continued from what was already discussed/planned in the sprint review for upcoming sprint, and hence it can start accordingly could be either PO or DT starting it depending on situation.

As quoted here from the guide - 

<The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.>

Also this can reduce chances for sprint goal being obsolete as stakeholder also collaborates to plan what to do next.

Thanks Ian, Stefan.

As per my understanding, During Sprint Planning - the Dev Team will choose the stories from Product Backlog...which they feel they can deliver during Sprint. As of now this is just a second sprint for the team (almost everyone is new - including PO & the team), PO is insisting to take more user stories (as buffer) on top of the stories which Team has chosen for the Sprint. Is this process correct? 

As per PO, it is Okk if Team deliver less user stories than planned. But insisting for big count of stories in Sprint Backlog.

Interested to know what scrum methodology says here...as per my understanding adding buffer user stories (due to push by PO), when Team is not ready...is wrong.

With these concerns and behaviors in evidence, do you think that team members might make better use of the Scrum Guide?

PO is insisting to take more user stories (as buffer) on top of the stories which Team has chosen for the Sprint

It is simply not Scrum for a PO to "insist" that the Development Team accommodate more items than they are comfortable completing within a sprint.   Only the Development Team can accept items into a sprint.

The business must "respect" the judgment, estimation, and capacity evaluation of the Development Team for planning a sprint.   To do otherwise violates one of the 5 Scrum values (respect).

While I truly agree that it is not right to insist on taking more, depending on how the scrum master will handle the situation, something positive might come out of it. In my view, this would be the realization that 1, the team can only output so much in terms of whatever scale your team uses for planning. 2, I think it would also be a good opportunity to use the retrospective with all members present and find a decent way to bring the point to the attention of the team.

I would somewhat disagree to refer to the guide as some sort of mediation point but more use the information inside it to make the best use of the events and therefore enhancing the impact of a working framework.

Feel free to disagree, this is just a suggestion, I do not know your current work environnement.