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.
Estimating in Scrum using Story Points
In Scrum, the Product Backlog consists of a list of Product Backlog items. The amount of time needed to complete a Product Backlog item needs to be estimated, primarily to aid in Sprint Planning and sorting the Product Backlog. Estimating in Scrum can only be performed by the people who are going to do the work, ie: the Development Team.
Estimating is best done in the presence of the Product Owner, who can answer any questions the Development Team may have. Product Backlog item estimates are provided, and owned, by the Development Team 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 Development Team, estimating sessions should be attended by as many Development Team members as possible, who reach consensus on the estimate.
In Scrum, Product Backlog items are often measured in Story Points. The value of a Story Point is decided by a Scrum Team but it’s usually based on relative estimating where you simply size one Product Backlog item relative to another. That is, you take the Product Backlog item that is the smallest and put it at one end of the scale. You then take the Product Backlog item that is the largest and put it at the other end of the scale. You then take all of the other Product Backlog items and size them relative to each other. Scales can be anything you like but are often based on an adapted Fibonacci sequence or t-shirt sizes.
The amount of Story Points that a Development Team 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