Estimation of stories

Irrespective of how many story points we assign, we expect the team to commit that they will complete the story in a given sprint if it has been taken up during planning session.

I'd suggest that the Sprint Backlog represents a forecast of work for meeting a Sprint Goal, and perhaps it is the Sprint Goal which ought to be the team's agreed commitment.

Do the team consider the selected user stories to be sufficiently refined and "ready" for Sprint Planning, so an achievable forecast can then be made?

Thanks Ian. The team (esp. Tech. Lead) has to refine the stories during the grooming session so they need to keep aside sometime in the current sprint to groom the stories for next sprint. But my question still remains if they don't decompose the stories into mandays how will they complete the stories to meet the sprint goal? May be the sprint goal isn't achievable at all but then effort estimation has to be done. Pls correct me wherever I am wrong. May be something fundamentally is wrong in my approach/question.

I'd recommend considering the Sprint Backlog as a forecast. There's always uncertainty and ambiguity, regardless of if or how you estimate. You may discover that you missed necessary work, that identified work is unnecessary, or your capacity changes. Rather than committing to a backlog of work, it's often more viable to commit to a goal and ensure that the known work to achieve the goal fits into the capacity of the Sprint, with a sufficient margin for error and uncertainty. Personally, if I'm working with a team that wants to allocate work to the goal, I suggest keeping the work allocated to the goal at about 60% of capacity.

However, even if you consider the Sprint Backlog as a forecast, your team probably wants to be reasonably comfortable with the forecast. If they are more comfortable working in ideal person-days or ideal person-hours, I don't see why they shouldn't use those units instead of points.

But my question still remains if they don't decompose the stories into mandays how will they complete the stories to meet the sprint goal? 

Try looking at it the other way round. If they were to decompose the stories in such a way, would it help them to meet their actual Sprint Goal commitment?

But my question still remains if they don't decompose the stories into mandays how will they complete the stories to meet the sprint goal?

I'm going to take a different tact.  How often have you known an individual to tell you exactly how long some type of work will take and then be correct?  "I'm running to the store, will be back in an hour.".  What if there is traffic accident? What is you see a friend and start a conversation?  What if you actually go to the store, get all of your items, get back in the car and go home but get back in less than an hour?  "You are number 5 in the queue and your wait will be 6 minutes". "Give me a minute to finish this email." "Lose thirty pounds a week with only 5 minutes of exercise a day". "This will only take 5 minutes of your time".  You can never be sure exactly how long something will take.  And the attempt to do so usually fails while creating a level of disappointment in the people doing the work.  Human nature is to over estimate so that the chances of failing are even less when you are frequently held to guesses based upon limited information.   

The Sprint Goal is defined before pulling items into the Sprint Backlog.  Items should be selected that will satisfy the Sprint Goal and the team makes a decision on whether they feel the items can be done during the Sprint timebox. Their decisions should be respected by everyone.  The Developers meet daily for 15 minutes to discuss how they are progressing towards satisfying the Sprint Goal. If they feel there is too much work, they can bring up the topic with the Scrum Team and work out a solution.  Same can be said for if they feel they will have extra time. 

D you think such commitment is not even required but then how PO would plan their roll outs for features?

There are many ways to plan roll outs but as everyone has said it is better to forecast.  Many metrics like Throughput, Cycle Time, Aging Work In Progress can be used for forecasting.  Monte Carlo analysis is a great way to do the same work.  But in Agile you aren't planning to a schedule.  You plan to a timebox (Sprint) knowing that the plan is flexible.  Forecasting is recommended.  A plan is a series of steps defined to take you to a specific destination.  A forecast is a series of decisions that will help you achieve a goal.  In both cases, the destination or goal, could change but it is easier to adjust if you are constantly making decisions and not constantly completing a predetermined set of steps.

Hi, All members stressed that team should commit to Sprint goal rather than backlog. My question is whats the difference? Generally, our team after they have picked up couple of stories for a sprint - PO creates the Sprint Goal. Is it an incorrect practice? Even otherwise, for each sprint, if team has to commit to the Goal, that automatically means team should complete all the stories in that sprint. Thoughts pls.

Generally, our team after they have picked up couple of stories for a sprint - PO creates the Sprint Goal. Is it an incorrect practice?

How reasonable do you think it is that one individual should make other people's commitments for them?

Even otherwise, for each sprint, if team has to commit to the Goal, that automatically means team should complete all the stories in that sprint. Thoughts pls.

Why? What purpose would the Sprint then serve? What would make that particular selection of work worth doing by that team right now?

The Sprint Goal helps the team decide what Product Backlog Items to pull into the Sprint Backlog.  The Sprint Goal should be created before the Sprint Backlog selection takes place.  From the Scrum Guide's section describing Sprint Planning (emphasis by me)

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

The Product Owner crafts the Product Goal but the entire Scrum Team crafts each Sprint Goal. One thing to note is that there is nothing that says every Sprint Backlog Item has to support the Sprint Goal.  But there should be enough of them to satisfy the Sprint Goal as that is the primary reason for the Sprint.  So you could have a few stories unrelated to the Sprint Goal, such as something to address a specific technical debt issue or an issue that is in Production and needs to be solved.  But the majority of the work should be in support of the Sprint Goal.

So you commit to the Sprint Goal and make sure that all of the items in the Sprint Backlog that support that goal are focused on to be completed.  Anything extra that you can accomplish in the Sprint is a bonus.