✥ ✥ ✥
It is important to have reliable estimates. Customers are happiest when their expectations are met. A team wants to realize the success that can result from properly sizing the work of a Sprint: too much work for the Sprint and stakeholder expectations suffer; too little work for the Sprint and the team is left with extra time on their hands for which work has not been planned or prepared. The same problems extend to longer time horizons, of delivering something several Sprints too late or several Sprints too early. However, if you spend a lot of effort estimating in days or hours, and your velocity changes, then the estimates are all wrong, anyhow.
Part of being reliable is to be up-to-date: to ensure you are bringing the most current knowledge to bear. It’s hard to be up-to-date if it takes a long, boring exercise to torture estimations from the team.
The Product Owner needs to know when a set of features will be done to be able to provide an estimate for a release date. The natural inclination is to ask people to estimate the number of hours required to finish each item, and then to add up the hours required to finish all desired features and to project that number onto a calendar, presuming a fixed team size and a 37- or 40-hour week. However, the estimates for work completion don’t account for “in-between work” activities such as meetings, doing Email, administration, the costs of context switching, and even of many business tasks (including work ordering and estimation itself). A typical work week is much shorter than 40 hours, with teams more typically spending about half that much on focused work. A Harris Poll survey found that people spend only about 45% of their time on “primary job duties.”  But the truth is, nobody really knows how many of those 40 hours are “overhead” and how many are “real work.” That makes it hard to know how many weeks it will take to accomplish a given number of hours of work.
Estimates are not intended to be viewed as commitments. An estimate is merely a forecast of the effort that might be needed to accomplish work. If the team is using absolute estimation units such as days or hours, stakeholders may be tempted to calculate a possible availability date for a given item assuming, say, a 40-hour work week for each team member, and to challenge what the team forecasts as a likely release time based on knowledge of their own pace. The difference between the stakeholders’ naive calculation and the team’s more informed calculation breaks down trust between them, and any attempt to explain away the disparity as a difference between real hours and ideal hours may be viewed with suspicion.
The Development Team needs to measure how process improvement affects their capacity for work. Removing impediments may cause velocity to increase. Without a velocity measure based on estimation points, it is difficult and often impossible to assess the results of an intended process improvement.
The Development Team and the Product Owner want to have a certain level of accuracy in the estimation. People have difficulty estimating in absolute units (e.g. meters, days).   Estimating in relative units is proven to be a more accurate alternative.  When using absolute estimations the units we use for estimation imply a corresponding duration. People can agree on the size of a thing like a 100 meter track but they will have a hard time agreeing on how fast it takes to run the 100 meters. We can agree that running 200 meters will probably take more than double the time as for 100 meters, though we may not be able to agree the time for either. Experience will tell us how long it will take to run 100 meters, which means that we should be able to project how long it would take to run twice as long.Therefore:
Use unit-less numbers for effort estimation. Use relative estimation, starting with a widely-understood and simple work item whose effort in Estimation Points can be used as a baseline for the rest.
To estimate Product Backlog Items, the initial baseline can be some PBI about which the team has consensus understanding. For the Sprint Backlog it can be some task, deliverable, or other unit of measure of the Development Team’s choice, for which the team has consensus understanding of the likely effort involved.
✥ ✥ ✥
Having a velocity “standard” in hand, the Team can derive their velocity as a basis for prediction and improvement. See Running Average Velocity and Aggregate Velocity for common ways to apply the idea of velocity in the Scrum framework.
Poker-planning   is a modern implementation of the Delphi technique that has proven to be an excellent approach to generate estimation points. Poker-planning is based on a nonlinear scale (approximately the Fibonacci numbers) that helps break down linear thinking. The main idea behind the use of the Fibonacci series is that the distance between allowable estimates increases as the estimates increase, reflecting the increasing uncertainty with increasingly high estimates. To help weaken any faith that might remain in the precision of large estimates, larger Fibonacci are rounded down (21 becomes 20, because 21 has too many significant digits, etc.).
A team often anchors its poker-planning exercise with a baseline. The baseline is usually a small number (1, 2 or 3) that is tied to a relatively Small Item to Estimate, with which the Development Team has high familiarity and confidence. After the first round of estimation every item is a baseline, by transitive closure of relative estimation. This obviates the need for, for example, reference stories.
Some teams give a pessimistic and optimistic estimate for each item to caveat their forecasts. It is common Scrum practice to instead give a single consensus estimate for each item, and then separately to derive confidence ranges empirically from historic data. This makes estimation go faster and provides a solid foundation for believing that the confidence range is something other than an arbitrary attempt to avoid blame. See Release Range.
A common practice in Scrum is to call Estimation Points “Gummi Bears.” This name is first mentioned by Ron Jeffries in 1999 (later attributed to an XP project led by Joseph Pelrine). 
A survey jointly sponsored by CA Software and the Software Engineering Institute (SEI) at Carnegie Mellon University, of 50,000 agile teams , has found that for the 90% of the respondents, using Estimation Points is better than a hybrid approach that still uses hours for Sprint Backlog Items, which in turn is better than the “no estimates” technique, which in turn is better than estimating in hours.
Estimation points are just a technique. A team can regularly improve its use of this technique to avoid common pitfalls. The most important problematic pitfall is to not involve all the developers; the second most problematic pitfall is to allow undue influence from anyone else. There are more refined improvements to the technique that nonetheless can make a lot of difference; see . The key points to remember here are that the pace of the schedule should be set by those carrying out the implementation work, and that people are very bad at reckoning estimates in absolute time units.
 Bourree Lam. “The Wasted Workday.“ In The Atlantic, 4 December 2014, https://www.theatlantic.com/business/archive/2014/12/the-wasted-workday/383380/ (accessed 2 November 2017).
 Jeff Sutherland and J. J. Sutherland. “Wedding Planning.” In Scrum: The Art of Doing Twice the Work in half the Time. New York: Random House, 2014, ff. 118.
 Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Reading, MA: Addison-Wesley, 2012, ff. 125.
 James Grenning. “Planning Poker or How to avoid analysis paralysis while release planning.” https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf, 2002 (accessed 2 November 2017).
 Mike Cohn. Agile Estimation and Planning. New York: Prentice-Hall, 2005.
 —. “Agile Practices Timeline.” AgileAlliance.org, https://www.agilealliance.org/agile101/practices-timeline/ (accessed 2 November 2017).
 —. “The impact of agile quantified.” ProjectManagement.com, http://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf, n.d. (accessed 13 November 2016).
 Magne Jørgensen. “Relative Estimation of Software Development Effort: It Matters with What and How You Compare.” In IEEE Software 30(2), March-April 2013, pp. 74-79.