Planning vs. Refinement

why do so many people estimate during planning sessions?

When you see this happen, would you say that the teams involved have a good understanding of what it means for work to be “ready” for Sprint Planning?

Ian's coaching style just nails it all the time. His question captures the essence.

I'm not as experienced as him, so I'll have to present my thoughts in phrases :)

Yes, estimating stories can be done during sprint planning, and there's nothing wrong with that. However, in doing so:

• the entire team needs more time for the planning session: DT to estimate, PO to possibly reorder the backlog and come up with a new vision, DT to pull what they think they can achieve, team to draft a sprint goal, DT to break down some work in order to start, etc
• stories that are critical to the business (PO) could be left not estimated (or estimated at really high numbers) due to the DT's lack of understanding, or due to more conversations required, or advice needed from others (domain experts?), or dependency being identified, or solution impossible to implement, and so on
• the PO would not have an accurate understanding of the backlog and, therefore, the order would not be the most appropriate one
• there would more time required for the meeting, which, in turn, would lead to less focus, more fatigue and reduced productivity. Keep it simple.
• and I can go on

Hence the practice of having conversations (backlog refinements) before the sprint planning. Note, however, there's no exclusion in place: that is, estimating during sprint planning doesn't exclude estimating during refinement; viceversa, estiamting during refinement doesn't exclude estimating during sprint planning.

All evidence points out it is way better to have the bulk of the estimation done in backlog refinements. And, of course, if there are new requests from the business (say an urgent insurance regulatory fix for an issue that was just discovered and said fix needs to be applied otherwise massive fine's going to be applied), those would of course have a place to be discussed - and estimated - during sprint planning. 

I echo @Eugene's comment on @Ian.  I am learning a lot from his Yoda like responses. Good thing he has a picture on his account or I would be picturing Yoda as I read his responses.

Both @Ian and @Eugene are correct with their answers. I've worked with teams that have done both and one team that actually did both at the same time.  It boils down to what the team feels is the best way to accomplish the task of estimating the work that will be included in the Sprint.  Yes, there is the "no estimate" movement but I'm not going to get into that beyond saying when a team of mine tried, they went back to estimating after 2 sprints. 

One thing I always point out about estimates are they are not much more than educated guesses so do not read more into their value than their use for getting some idea of what the team feels that they can get done. 

"estimates are... not much more than educated guesses so do not read more into their value than their use for getting some idea of what the team feels that they can get done"

Exactly!

So, in the Planning Meeting it is good practice to only ESTIMATE (Planning Poker) PBIs that have already been refined or only refine PBIs that you want to include in the Sprint but, for some reason, have not had time to refine before. Is this correct? 

Thanks!

I can't say you are wrong @Joan Moreno i Maurel but also can't say you are right.  This is something that your team needs to decide.  

I do, however, coach that you make every effort to refine items prior to Sprint Planning.  The goal of Sprint Planning is to pull the items from the Product Backlog that the team understands well enough to believe they can be done during a sprint.  There are times that something in the Product Backlog that the team has not had adequate time to refine might be included.  There are also times that something newly discovered could lead to the need to add a brand new item.  But those should be the exception and not the norm.  Those activities increase your risk of successfully delivering increments of value and could hinder you from being able to react to information gained while doing work that you felt you already understood.  They also impact your consistency of work delivery.  The more you can approach a sprint with a confidence that you understand the work, the better suited the team will be to reacting to new discoveries while doing the work.  

So, in the Planning Meeting it is good practice to only ESTIMATE (Planning Poker) PBIs that have already been refined

Can a team refine items, and thereby make them Ready for Sprint Planning, without estimating how much work will be involved?

or only refine PBIs that you want to include in the Sprint but, for some reason, have not had time to refine before. Is this correct?

There is a need to refine work and make it Ready before the Sprint Planning event commences. There's nothing to stop this from being done immediately beforehand, and it does not necessarily have to be taken care of in a separately arranged meeting.

Bear in mind that the Sprint Review is a formal just-in-time opportunity to ensure the Product Backlog is in the best possible shape before Sprint Planning.

Daniel Wilhite and  Ian Mitchell thank you very much for your fast replies! :)

After your answers, I still think that refining in the Planning may be too late in some cases, it will be better to spend a little more time refining and estimating during the Sprint, and the Planning will surely take us less time than the maximum of 4h (in two weeks Sprints). We will do it like this to start.

Joan Moreno i Maurel Refinement is an ongoing activity during the sprint. Activities like breaking down the product backlog items to smaller and precise items, adding details like description, order and size making it 'Ready'  for sprint plannning. Yes it helps to keep the sprint planning within timebox.