Sprint planning out of the timebox

Why are you estimating your work in the Sprint Planning session? How much effort is your team expending toward refining the Product Backlog before Sprint Planning?

None, so far.

If we estimate during the refinement meeting, what's the purpose of the Sprint Planning then?

We made only one meeting of refinement and we've only talked about the stories splitting. The most of the stories in the backlog were too big.

The refinement is not made with all the team. It includes the tech leads only.

Also, thanks for your question, but do you have an answer for me? Do we need to plan another meeting to complete it?

Were you able to plan sufficient work for the first few days of the Sprint?

@Ian : Yes, but not that much. 4-5 days, maximum.

If we estimate during the refinement meeting, what's the purpose of the Sprint Planning then?

Estimating in refinement gives the team the ability to build up a list of stories of which they are familiar so that when it comes time for Sprint Planning, it is easier for them to decide what stories to pull into the Sprint Backlog. In all of the groups I have worked estimating a story is a final indicator that stories are ready to be pulled into a Sprint Backlog.

The refinement is not made with all the team. It includes the tech leads only.

Starting with this statement from the Scrum Guide section on Product Backlog

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. 

Notice that it says the Product Owner and the Development Team takes part in refinement.  That is because anyone on the team might have information that others don't.  Do your tech leads have all the information and expertise that the rest of the Development Team contains?  How much does the rest of the Development Team actually understand about the problem statement and work associated to a story?  

I feel that your lack of refinement and inclusion of the entire team is what is leading to your Sprint Planning taking 8+ hours.  If you are estimating during Sprint Planning and it is taking that long, I assume that there is significant discussion occurring in order to estimate.  This is how refinement helps the situations. 

What to do next? Do we have to plan another Sprint Planning some days after the beginning of the sprint?

To answer these questions I say you should be improving your refinement activities so that going into Sprint Planning the stories are better understood and Sprint Planning can focus more on the how the Development Team plans on addressing the stories. Spend less time on the why and what associated to the stories during Sprint Planning and move those areas to refinement. As for the current Sprint, if you were able to craft a Sprint Goal and can deliver an increment of value based on the current contents of the Sprint Backlog, I suggest going forward on the forecast work.  Use any extra time available to further refine the Product Backlog with participation from the entire Development Team. 

@Daniel : What an eloquent answer! Thanks a lot. Really helpful!

I don't have much more to say beyond what Daniel Wilhite said, but I would also point out that the Scrum Guide states that the refinement activity "usually consumes no more than 10% of the capacity of the Development Team". However, unlike the events, this isn't a timebox. You may need more time, you may need a little less. Significantly less time, however, would raise some questions and I'd keep an eye on that.

If you're being successful at refinement and your Product Owner is maintaining a well-ordered Product Backlog, your Sprint Planning sessions become very easy. You have a chunk of work that's reasonably well understood by the Development Team and the Product Owner has an understanding of the effort required to complete each piece of work. The discussion centers on how to best deliver the work.

Thanks to you too Thomas Owens. Really appreciated.