Planning meeting include a mandatory estimation process or not?

Estimation is part of Product Backlog Refinement activity. Refined Product Backlog Items are necessary before Sprint Planning. However, the Scrum Guide leaves the estimation techniques up to the Scrum Team. Estimates are designed to help the Product Owner understand the time, effort, and complexity of work to assist in ordering the Product Backlog, so any type of estimation techniques that help the Product Owner understand this information is sufficient.

Does Planning meeting include a mandatory estimation process or not

Mandatory?  No.  Optional? Sure if your team feels it is best.  Some teams will estimate during refinement, some during Planning.  There is no right time to do it. It is only recommended that it be done in order to better understand the work that needs to be done and help the Development Team determine what work to pull into a Sprint Backlog.

And how estimation is performed?

My personal opinion on this is however the team feels is best for them.  There is no right way to do it and it will vary from team to team. There are a lot of suggested practices you can find on the web and in other posts in this very forum. But there is no right way.

Can you explain it in details, pls.

See my previous answers to know why I say "No, I can not". 

Estimation is one of the more widely discussed and disagreed upon parts of Scrum. There are many ways to do it and every one of them is correct for at least one Scrum Team.  I suggest that instead of trying to find the definitive answer to this, you read as much as you can on the reason for estimation and some of the practices used.  Then work with your team to help them understand the benefit of doing it and arrive at a method that works for them. 

I'll also say that you will also find bodies of work around the #noestimates movement.  Is it wrong? I'm not going to say it is but the Scrum Guide mentions many times that one of the attributes of a Product Backlog Item is an estimate.  But there is nothing in the guide that says how to arrive at the estimate or even what exactly it means. Again, you will have to find your own way on that.   

I know it isn't the answer you were looking for but, for me, this is the best I can give you.

I'll also say that you will also find bodies of work around the #noestimates movement.  Is it wrong? I'm not going to say it is but the Scrum Guide mentions many times that one of the attributes of a Product Backlog Item is an estimate.  But there is nothing in the guide that says how to arrive at the estimate or even what exactly it means. Again, you will have to find your own way on that.  

My interpretation of #NoEstimates is that it relies on breaking items down to be small enough to work on.

The decision that something is small enough, could be considered an estimate. This estimate could be explicit, by answering a yes/no question, or implicit by not choosing to break the item down further.

Does Planning meeting include a mandatory estimation process or not?

>> As per the guide - 'Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done.” '

What do you interpret from the Guide ? What will be the effect on transparency if the backlog items are estimated much earlier than planning?

The decision that something is small enough, could be considered an estimate. 

The team is effectively estimating that Product Backlog items are of equivalent size. It's a valid approach to estimation in Scrum, despite the #noestimates moniker.

What do you interpret from the Guide ?

Attributes don't have to be set. So estimating is not mandatory, but maybe best practise.

I wasn't going to say anything more about the #noestimates thing but since @Simon and @Ian gave exactly the same opinion/interpretation I have I decided I'd +1 each of them.  It is human nature to estimate work before you do it, whether you want to admit it not. 

If estimates are not done:

How team will able to get confidence, if work item is small enough to cover in a sprint?

As per Scrum Guide:

Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

I believe estimation, allow team to forecast what team can deliver in sprint

More the strong estimates, more confidence for team in what can be delivered in Sprint. Estimate are basis of (plan) how team will build the functionality in Done increment.

But yes, it’s totally up to self-organized team, what approach team want to use for estimation and up to what granularity level estimation are required. This also depend upon team maturity and experience on specific estimation approach

Again, as per Scrum Guide “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.”

so, if we need to decompose any tasks by unit of day or less then we have to do estimate of items 😊

 In my view there is no need to estimate all PBIs upfront, I recommend if tentative PBIs for next 2 sprint are having required details order, value and estimate.

Healthy product backlog will lead to shorter sprint planning and team will be more confident in sprint planning for forecasting

 “What can be delivered in the Increment resulting from the upcoming Sprint?”

Note: Please note I mentioned “In my view team need not to estimates all work items in product backlog” because it’s not recommended to spend lot of time for details and estimates for the items which are not clear or which need to be Done after 6-month(long time) 😊

Regards

Sunil Gulia

Thank you all for your informative comments!!!