Estimation & Planning

Scrum doesn't forbid making estimations during Sprint Planning. I would say this is usually the last point in time it can be done before actual work on the Sprint starts. Some teams in fact don't do any estimations at all. They are able to cut the PBIs of the equal size and estimation becomes reduntant. Some teams are able to do Sprint Planning so effectively that they don't need PBRs at all.

Imagine a situation that after Sprint Review the Product Backlog is updated and PO decided to insert a new feature at the top of it. You don't have any time for PBR before the Sprint Planning.

Capacity can be calculated as you wrote but is also can be thought of as a "gut feeling" of the team. It's not mandatory to be calculated in ours.
Scrum doesn't prescribe using stories. It's just a good practice.

There's no "correct" way of doing Sprint Planning. What you're talking about is just some practices. Some can be appropriate for the DT, some not. Follow the Scrum Guide defininion of the Sprint Planning.

> most of the time the stories are customer defects and require research and analysis

If that is the case, would you say you have clear Sprint Goals? Remember that the goal is the purpose of the Sprint, and estimates are a means of determining how much work the Development Team can take on.

As Illya says, some teams cut the PBI's to be of roughly equal size. That can be a viable research & analysis technique in its own right.

I agree with Illya as far as the PO's perspective is concerned. For me as a PO, I am responsible for the Backlog and wnat to have estimates as soon as possible on the one hand, but do also not want to disrupt during Sprints on the other hand.
That is why we sometimes do estimations during Planning.

Estimates in the backlog serve two purposes:

1) to determine priority. Since it is the PO's job to maximize ROI, he will need Effort vs Value in order to make a judgement on priority. The ROI calculation can be done at the epic level or story level depending on the needs of business.

2) to do release planning. effort estimates in the product backlog in conjunction with velocity will provide a projection on future release(s).

So long as the PO is able to maximize ROI and appropriately plan releases for the business needs, how and when estimation is done becomes a irrelevant.

For me, estimate is useful to convey the conversation among users / PO / dev team.
The point is not about having "accurate" estimate, (is this PBI 3 or 5 points, and this one 8 or 5 ?) but having a good understanding of the PBI.
It should be done before the Sprint Planning Meeting, in order to have enough time to discuss the 2 topics (what & how) & craft the sprint goal.
If this is not done before the Sprint Planning Meeting, most of the time is spent one the estimates, and the "how" and the sprint goal are just skimmed.

Mouli,

What your team is doing does not violate Scrum, but they may be using practices that are suboptimal. So, while your team may be using the Scrum framework correctly, they have not yet optimized how they *implement* Scrum, or "fulfill" the framework.

I'm a big believer in refinement (formerly called grooming), and my suggested practice is to get 2 sprints ahead on refinement.

More here:
http://scrumcrazy.com/bugs
http://scrumcrazy.com/pbr

Thank you all for your precious suggestions and opinions