How to estimate point for each of Product backlog before Sprint Planning?

Forecasting should be done by the Developers during sprint planning and during product backlog refinement along with the PO. 

Although your method may seem sound on the surface, you are in fact offering a commitment to the stakeholders when using the word estimate, which is why forecasting in now used. 

Scrum is used for complex products, and the majority of the information about a complex product is not known, which means that there is a large amount of uncertainty at the beginning of each sprint until more information is discovered whilst working on each PBI. 

The product backlog and sprint backlog should be good enough for the stakeholders to see how the product is progressing.

The scrum team is accountable to create a usable and potentially releasable increment at least once a sprint, allowing the PO to decide to release that increment or not.

Could you share your current methodology or formulas to estimate point for each of Product Backlog while you are making a plan for a month, quarter or year.

In Scrum, the only purpose of estimation is for Developers to get their arms around how much work they can take on each Sprint and finish to Done standard. Everything else reduces to empiricism and value delivery, the rate of which is then evidenced. That's it.

For example I have 100 product backlog to finish new requirements but I can NOT wait sprint by sprint to answer stakeholders when will be done. 

Won't valuable work be Done for stakeholders each Sprint, every time?

Now we use Fibonacci to estimate for every single PBI, if any PBI larger than 21 we will divide into smaller PBI. I use some criteria to estimate point such as complexity of screen, logical condition. After that I will have about 800 points for 100 PBI then based on velocity of our team to answer the deadline to stakeholders. We will finish after 7 sprints. Total duration is about 4 months from now.

What is your role within the Scrum Team? Only those that are doing the work should be estimating the efforts.  And even when that occurs you only get an estimate which is nothing more than a guess based upon information known at the time the estimate is made.  Why not try to use other measures that are based upon actual work?  

Measuring cycle time, lead time, throughput, work in process history/limits can all help with forecasting when something could be done but even then it is a forecast.  Just as is done by weather experts.  A weather forecast is based upon modeling past situations and arriving at an outcome with the highest probability of being correct. 

I'm a big fan of and going to suggest you read these books by Daniel Vacanti. 

1.  Actionable Agile Metrics for Predictability
2. When Will it be Done

When a team can achieve predictability, the ability to present reliable forecasts emerge. Your entire Scrum Team should read them so that there is a common understanding.  If you use Jira, there is an ActionableAgile addon that will produce all of the reports mentioned from your Jira data.  

Thank you guys for your supporting however let's me clarify.

As far as I know Scrum framework to guide us to implement sprint by sprint well known as DO process instead of PLAN.

I am a PO an I need to make a release plan, but how do I know how many point and sprint to release before Developers are doing estimation at the Sprint Planning? 

Again, stop thinking of using points in that manner.  They aren't for forecasting future and there is no real "completion" of points.  Points are only used for Developers to understand the complexity of the work based upon what they know before work begins.  Using that and knowledge of how they work together, they can make an assessment of how much work they are comfortable taking into a Sprint Backlog.  But everytime Developers undertakes work, their ability to estimate improves.  Every story is unique and everytime a developer works on a story, they learn new information.  So the complexity associated to a 13 will change over time. 

The books I suggested will show you ways to do the forecasts you need.  And sharing them with the entire team will help them improve their consistency which leads to even better predictability. 

Hello Max,

I can understand that your concern is that you want to give a high-level planning schedule for your 100 PBI (release plan) to your client/customer in advance and you don't want to wait for the upcoming sprints.

In our organization for this situation, we are using some concept/part from the "https://www.scaledagileframework.com"

so, I am talking about "IP Iteration" and "PI Planning". here in "PI Planning", we are doing four sprints of advanced high-level planning after discussing dependency and risks between different teams. 

You can read more regarding IP Iteration and PI planning in detail.

So, in this way you can give a high-level time schedule to your customer. ( again it is just high-level only). During actual sprints, requirements may change or re-prioritize based on customer need, feedback, market condition etc.