How often and how long should we conduct product backlog refinement meeting in a 2 week sprint?

Have you asked the Development Team what they think is best, considering that up to 10% of their time may be planned for refinement activities?

@Ian Mitchell's question is the best answer you will get. But I will add these questions to supplement his. Why do you have to hold a meeting for refinement to occur? Are there other ways that refinement can be done that does not require everyone to sit in a room at the same time? Isn't understanding the items in the Product Backlog in such a way that the Development Team can address them part of what they are expected to undertake? If they are not accounting for that are they really meeting the needs that the organization expects them to address?

On a side note, I want to say something about this one question you asked.

If the development team has estimated work for the entire sprint means they do not have any extra bandwidth then how can we adjust time for PB refinement meeting?

I would caution you to be very watchful on this. If a team is estimating that they will be busy every hour of every day before they even start working, I would see that as setting themselves up to failure. Leaving no time to react to new information, someone getting sick, an unexpected event that could cause disruption such as a having to evacuate your building do to some emergency is going to ensure you will have problems meeting your goals in the long term. 

With respect to scheduling a Product Backlog Refinement meeting, that should be up to the team. However, it's not an event and everything can be done outside of a meeting. That said, the teams that I've worked with have tended to prefer a short (maximum 1 hour, in case some additional refinement needed to be done) meeting to look at what has been refined and synchronize on it to make sure everyone (even those that may not have been actively refining it as much as others) are aware of what has been done. The time varies, but it's always with sufficient time before Sprint Planning to ensure that any necessary work that comes out of this meeting can be done prior to Sprint Planning to ensure well-refined work.

The more concerning thing is that the Development Team is planning a Sprint such that they have no extra bandwidth. Not only should their be a reserve of time for Product Backlog Refinement, but what happens when other unexpected events come up? These "unexpected events" could be production support related issues that are critical or company-related events from outside the Scrum Team or some kind of unplanned leave taken by one or more Development Team members. If your Sprint Goals and Sprint Backlog require the ensure team to be at 100% capacity and effort for the duration of the Sprint, there is a high chance of something coming up that disrupts that. The tolerance for not completing the forecast does depend on your organization, but all of these things should be considered at Sprint Planning.

Thank you so much Daniel Wilhite, Thomas Owens for your detailed explanation.

Ian Mitchell I am from the development team and learning about scrum in deep :) .  

Asking the development is great but what if the development team is new to Scrum framework and doesn't have much knowledge about all these events. In this situation, someone has to guide them by telling the importance of PB refinement.

From your answers, this is what I got to know - 

• How often we conduct a PB Refinement meeting?  (Depends on the development team)
• What is the optimal time duration for the PB Refinement meeting? (Again, Depends on the development team)
• If the development team has estimated work for the entire sprint means they do not have any extra bandwidth then how can we adjust the time for PB refinement meeting?
  
  (We (the development team) should never estimate to 100% time of the sprint. There must be some bandwidth (maybe 10% of the time) to unexpected work )

From the 3rd point (This is what I think) - If the development team has some bandwidth and fortunately there is no unexpected work or event in the sprint then the development team must pull some work from PB and must inform PO about it.

If the development team has estimated work for the entire sprint means they do not have any extra bandwidth then how can we adjust the time for PB refinement meeting?

(We (the development team) should never estimate to 100% time of the sprint. There must be some bandwidth (maybe 10% of the time) to unexpected work )

Nitish,

Please note the 8th Agile principle:

Agile processes promote sustainable development.   The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

What this implies is that Development Teams should plan their sprints "comfortably".   Value Delivery and consistency in sprint execution should be the primary motivations for them.   

Utilization maximization should not be a goal for Development Teams.   I would even caution against using a % buffer for unexpected work, since that implies a utilization perspective in planning.

If the development team has some bandwidth and fortunately there is no unexpected work or event in the sprint then the development team must pull some work from PB and must inform PO about it.

While the Development Team does own the Sprint Backlog, I would strongly suggest that the Development Team collaborate with the PO regarding any changes to it (i.e. - pulling items from PB in response to excess capacity).   Remember that the PO's primary responsibility is maximizing the value delivered by the Development Team, and simply asking the Dev Team to "inform" the PO when they pull in additional work does not seem to support that Scrum responsibility.

Utilization maximization should not be a goal for Development Teams.   I would even caution against using a % buffer for unexpected work, since that implies a utilization perspective in planning.

Could not agree more! When people start talking about percentage of utilization, I always come back with "okay cool, let's plan for 40-50% at most because there is ALWAYS unknowns that come up and there is zero value in planning for so much time and then carrying over un-done work. Much better to plan a smaller amount of work and then if the team finishes it; they can always pull in more work.