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.
Story Estimates
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
Hi Derek,
I completely agree that the key outcome is to get some relative sizing of the backlog.
I would suggest that one of the most crucial things in the estimation is the discussion – so that the Dev Team and the Product Owner both gain a deeper understanding of what is being requested.
As the understanding of the business value is increased, they may break the story down further, add more detailed acceptance criteria, and enrich the PBI with more information.
Regards
Simon