This article is designed to present estimating in Scrum as quickly as possible and is necessarily terse. I assume that the reader has a basic understanding of Scrum. If you’re new to Scrum, this video by Lyssa Adkins explains Scrum in ten minutes.
in Scrum, the Product Backlog consists of a list of User Stories. The amount of time needed to complete a User Story needs to be estimated, primarily to aid in Sprint Planning and sorting the Product Backlog. Estimating can only be performed by the people doing the work, ie: the Development Team (DT).
Estimating is best done in the presence of the Product Owner (PO), who can answer any questions the DT may have. User Story estimates are provided, and owned, by the DT and not by any individual. This is because at the point of estimation, the individual who will do the work is unknown. Because the estimate is owned by the DT, estimating sessions should be attended by as many DT members as possible, who reach consensus on the estimate.
In Scrum, User Story estimates are measured in Story Points. The value of a Story Point is decided by a Scrum Team. It may map to a perfect work day, a work week, relative complexity, or any other form of measurement that the ST is comfortable with, so long as it remains constant. Perfect work days are often chosen as it makes guessing initial Velocity easier.
The amount of Story Points that a DT can complete within a Sprint is called the Velocity. Prior to the first Sprint, Velocity is an educated guess. The Velocity is then changed after each Sprint to reflect actual performance. This way, the accuracy of the Velocity improves over time, based on experience. To increase the accuracy, all Sprint durations should remain constant.
For a more in-depth look at estimating, I recommend the book Agile Estimating and Planning by Mike Cohn. Alternatively, if you want to explore the topic just a little further, I wrote another article on estimating and story points