... the team has a Product Backlog or Sprint Backlog in hand. The team uses effort estimates, both for Product Backlog Items (PBIs) and tasks (or other Sprint Backlog Items), to forecast, plan, and schedule work and deliveries. The Development Team manages itself as an Autonomous Team.
✥ ✥ ✥
The team should ground its estimates in reality rather than assumptions or wishful thinking.
Sometimes when new work comes in, a caring manager may want to protect the team from the work of estimating it, and may take the initiative to estimate it themselves. It will take the team some energy to undo a standing estimate, particularly if a manager, the Product Owner, or someone else in authority or with power over the team, imposes the estimate on the team.
Development efforts tend to rely on experienced people and experts to do estimation. But maybe the people who are going to do the work are less experienced, or the team has forgotten to involve an important area (as for example, test) in making the estimates.
A team might not feel responsible for the backlog when others determine the estimates. If the expert is within the team, a hierarchy might emerge and the team as a whole might not take ownership of the estimates.
Let the people who are committed to do the actual work do the estimation. In the Scrum sense it is pigs that estimate — not chickens (, p. 31; , p. 51; and , p. 123).
The terms Pigs (Development Team members) and Chickens (everyone else) finds its roots in the following joke:
A chicken and a pig are together when the chicken says, “Let’s start a restaurant!” The Pig thinks it over and says, “What would we call the restaurant?” The chicken says, “Ham n’ Eggs!” The pig says, “No thanks, I’d be committed, but you’d only be involved!” (From , p. 42)
The estimate should be a consensus generated from the perspectives of all relevant development areas. Research shows that estimates are much better when combining independent estimates, with iteration and feedback, from everyone who participates in development. Since Development Teams are cross-functional, it’s possible for the Development Team to create very good estimates together ().
✥ ✥ ✥
The team feels committed to ownership for its work. This is good in its own right but will also increase the focus that the team brings to its estimation efforts. Oh, and one gets better estimates in the long term if they come from the Developers.
In particular, the Product Owner (perhaps together with the Product Owner Team) estimates the Business Value, and the Development Team estimates the cost or effort necessary to complete the PBIs. Each of these groups can use Wideband Delphi  or any other technique to build a consensus view (see Estimation Points). It is particularly important to capture the perspectives of all members of the cross-functional Development Team.
The Development Team should continuously revise estimates as new information emerges. They can estimate newly created Product Backlog Items as they work with the Product Owner toward creating a Refined Product Backlog, and it is natural to review estimates at Sprint Planning. The Development Team can follow its intuition about which estimates to revisit in light of new information. Estimates also come up for renewal as the Scrum Team restructures the Product Backlog while building a Refined Product Backlog or striving for a Granularity Gradient.
In most applications of this pattern in Scrum, the estimate is only a forecast and stakeholders should never view it to imply a commitment. On the other hand, no one other than “the pigs” is allowed to speak to estimation. There should never be a ground for challenging an estimate à priori. For example, Product Owners cannot impose their wishes for delivery on the team’s grounded forecast about how long work will take. Empirical insights from experience over time will help the team adjust its estimates to be more accurate.
 Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct 21, 2001, p. 35.
 Mike Cohn. Agile Estimating and Planning, 1 edition. Englewood Cliffs, NJ: Prentice-Hall, 2005, p. 51.
 Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Reading, MA: Addison-Wesley Signature Series (Cohn), Aug. 5, 2012, p. 123.
 Magne Jørgensen. “What we Know about Software Development Effort Estimation.” In IEEE Software 31(2), March/April 2014, pp. 37-40.
 Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 42.
Picture credits: http://www.antiquegamblingchips.com/CelebritiesPlayingPoker.htm.