Estimation and Story Pointing
Generally, in order for a requirement to fully meet its Definition of Ready (DoR), the level of effort to complete the work must be estimated. The Product Owner and ALL members of the Team; not only development, but testers, user interface designers, database administrators, etc.; that are needed to complete the requirement should work together to identify the level of effort and establish an estimate.
What is Estimation?
An estimate is a rough calculation of the value, number, quantity, or extent of something. When used in Scrum (or Kanban), it is a point-based, valuation system for estimating the level of effort it takes to deliver a requirement, or user story. While estimates account for the level of effort to deliver “the product,” they are relative to the Team providing the estimate and will typically vary across teams. The valuation scale for estimates is usually reflected in terms of size, but most often as story points.
Assigning a numerical value (i.e story points) to relative estimates allows Teams (especially newly formed ones) to reach consensus about the level of effort needed to complete a requirement, or user story. By removing the implied precision of the numerical score, they increase the accuracy of capacity estimates and measurement for planning.
What are Story Points?
Story Points are an arbitrary measure used by Teams to measure the effort required to implement a user story, or requirement. The story points tell how hard the story is, the level of complexity, account for unknowns, and provide an indication of effort.
In terms of sizing, story points can range from extra small to extra large, but mostly commonly used is the Fibonacci series.
Fibonacci
The Fibonacci series is a mathematical sequence where each number is the sum of the previous two, with the scale being 1, 2, 3, 5, 8…and as a best practice, usually work that is an 8 or beyond should be further decomposed into more manageable chunks that can be accomplished within a sprint.
The Fibonacci series uses a range to help recognize uncertainty and removes the “emotional attachment” to hours and dates. Using the Fibonacci series guides estimation in “being roughly right over being precisely wrong.”
Estimation for Your Team
When estimating for your Team, there is no standardized approach other than the level of effort you think it will truly take to complete the requirement, or user story. Typically, most Teams will begin by using an estimation exercise to identify the “relative size” of stories in their Backlog.
Begin with a single user story and then compare each story in the Backlog to determine if it is relatively smaller or larger. As you compare the stories, a scale will begin to evolve. The stories with the smallest level of effort should be assigned a 1-point estimate while the largest should be a 5-point estimate (ideally, stories that are larger than a 5-point estimate should be decomposed further.)
While a consensus should be reached for each estimate, the level of effort should be reflective of the overall effort - experience of all team members, development, quality testing, user acceptance testing, etc. - in order to achieve the established Definition of Done (DoD).
Estimation and story pointing identifies the level of effort to complete a requirement, or user story, but avoids bias and influence. It should drive the Team’s discussion and understanding of a requirement. Story points should be updated accordingly as additional information becomes available. Understand that in the initial stages, estimates may be all over the map, but over time the Team will begin to produce an average velocity and burndown.
Good Reads
These are good references for estimation:
These are good references for story pointing and the Fibonacci series: