Sprint Planning kicks of the Sprint by planning the work to be performed during the Sprint and the Increment to be achieved.
The Product Owner (PO) sets the Sprint Goal, which is a high-level objective which can be met by completing the work planned. The PO bases this Sprint Goal on inputs such as work completed, work in progress, stakeholder feedback, and the vision for the product.
Work is selected from the Backlog and added to the Sprint Backlog, or Sprint Plan. This planning process requires some level of estimation. The team needs to define what can/can’t be done in the Sprint: estimated effort vs capacity.
Estimates are by their very nature forecasts based on what is known at the time. Techniques such as Story Points or t-shirt sizing add value to the process by giving the team a different way of looking at the problem. (See my post on this)
If you run regular Backlog Refinement ceremonies and/or have an up-to-date, prioritised backlog, I recommend 1–2 hrs for Sprint Planning.
To understand your capacity for the next Sprint it is good to know the teams Velocity (reflects how much work they typically complete per sprint), and also consider any planned leave and development needs, such as training.
Link to my original post.