Best Practices - Story Estimation

There's no such thing as a best practice when working in a complex environment. You may have good practices to draw from, but more likely will be building or composing your own practices that enable you to deal with the uncertainty in your environment.

That said, a good practice to consider is not estimating. The amount of time invested in evaluating estimation practices, choosing or implementing the practices, teaching and aligning the team on the selected practices, debating if and when to reestimate work, and discussing estimates versus actuals as work is completed takes a lot of time from a team. This effort rarely, if ever, adds value for stakeholders. If you focus on decomposing the work to the smallest units that represent deliverable value and track the team's cycle time and throughput, you can forecast when work is likely to be completed without the overhead of estimation and the baggage that it comes with.

As @Thomas said, there is no such thing as best practices.  There are just a whole lot of good ideas.  And his idea of not using estimates is a very good one.  I have found it to be true on many occasions.  

Another idea I will give is if you absolutely feel that you have to use estimates and story points, then you need to understand their purpose. I suggest reading this article by Ron Jeffries who is said to have created Story Points. It will provide you the origins and purpose of the practice.  

Story points and estimates are only useful until work begins. They are guesses made at a point in time based upon the information you had available. As soon as you start working on the issue, new information is obtained and the original estimates are no longer accurate. They should only be used by the Developers to gauge whether they feel the body of items selected in the Sprint Backlog can be completed during the Sprint.  After that, they should be ignored. Trying to use them to predict velocity or performance of the team is a bad idea. Especially since the team will adjust their estimates over time as they become more familiar with the problem domain and each other's capabilities. 

Could you share your best practices for story estimation   and story points ?

The only purpose of estimation in Scrum is so the Developers can get their arms around how much work they can take on and complete on a Sprint. Everything else reduces to value delivery and empirical process control.

Hi All

Thanks for the Feedback. This is helpful. I have been telling others in my Agile World, that the Sprint is just an estimation of work to be done and that Comparing Teams is a BIG no no.  yet they inisit that ALL teams MUST have the same estimation framework