Sprint Planning part 1: Selecting items for the Sprint Backlog

Hi Franck,
unfortunately it is not that simple. Software development is a complex process and the velocity varies with many factors. Just to name a few:
- Who will be working on the Sprint Backlog?
- Has the Definition of Done changed?
- Are there any new or removed impediments?
- Are there scarce skills in the team?
- Technological and business coherence
A self-organizing team can intuitively give a good estimation based on previous velocity and the factors above. To my experience this estimation is much better than a calculated "capacity" based on the available man hours. The reason is that people vary in skills and velocity and there are complex social processes in a team.
Best, Ludwig

> When backlog refinement and estimation is done before the Sprint Planning
> meeting and when the velocity of the team is known. Then what is the sense
> of the first part of the Sprint Planning meeting?

I look at it this way: backlog refinement and estimation, when done regularly and conscientiously, will allow Sprint Planning to go smoothly.

...and it's another opportunity to adapt. Furthermore it's important to ensure that there's a consensus due to prospective work for the next sprint. Sprint planning is your best chance to ensure that.

It is not necessary that always Product Backlog would be 100% groomed with estimated stories. Sometimes, PO is doing prioritization and grooming sessions in the spring planning meeting also. ( In the sprint planning meeting, PO may remove or add  some new stories  based on customer requirements, business demand and last sprint status).

So, an automatic filling spring backlog is not suggestable. 

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )

I was agreeing with you until the last sentence.  Sprint Planning is not about filling your team to capacity. It is about planning a body of work that will produce a valuable increment. If you fill to capacity, you have no ability to deal with the unknown. Also, how do you know how long an item will take to complete until you actually start working on it?  How often are people able to say exactly how long it will take to do something correctly before they even start the activity?  Can you say for certain that it would take you 2 hours to add 6 new plants to your garden?  Can you say it will take you exactly 2 hours to leave your home, go to the market, pick up a list of 9 items and return home?  This is why the original premise is flawed.  Plan your Sprints with a forecast of what it will take to produce an increment of valuable work, not based on a number that is nothing more than a guess. 

@Franck van der Sluijs I have a few questions for you:

• Does this approach ensure that goals are known?
• Does this approach (at least at the beginning of the Sprint) allow us to forecast what we deemed necessary to achieve Sprint Goal and other goals that we might have, like those related to continuous improvement of our process?
• How does it address this statement form Scrum Guide:
  • "(...) The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. (...)"
• Does "the first part" of the Sprint Planning event focuses on "filling capacity" or on creating shared understanding why we run this sprint, what goals we want to actually achieve?

@BHAVIN RANA as @Daniel Wilhite wrote, I also mostly agree with the first part of your comment, and I also don't agree with the last statement:

Team should pick stories one by one based on latest capacity planning ( available bandwidth of each team member )

This statement just simply treats Development Team members individually, like an independent cog, a resource that we need to utilize. This IMHO looks like some old-fashion PM BS that is unfit for complex problems that we try to address by empirical approach.