In agile software development, particularly in Scrum, teams usually use story points to give a relative size to their stories. The most common numbering system in use is Fibonacci Sizing. A true Fibonacci sequence goes like this: 0, 1, 1, 2, 3, 5, 8, 13, 21. Each number represents the sum of the preceding two numbers (starting at the third number in the sequence). When estimating story points, most teams use a modified Fibonacci sequence that starts at 1 and ends with 20. That is, 1, 2, 3, 5, 8, 13, 20.
Why use Fibonacci Sizing? It’s important to remember that sizing stories isn’t supposed to yield perfect estimates, but rather is an exercise in understanding scope and ensuring mutual understanding among team members. Even a well-groomed story that appears to include all relevant details will often end up with sizing estimates that vary wildly. Understanding why one team member estimated the story as a 2 while another team member estimated the story as a 5 should encourage conversation and may uncover new information or provide missing context to some team members. At the same time, arguing between 5 story points and 6 story points isn’t likely to be helpful. Using Fibonacci sizing reduces minor disagreements in scope for larger tasks.
Another important point about sizing user stories is to remember that they should be a measure of effort and complexity and not an attempt at estimating time. There are differing opinions on this point, but a point in favor of estimating effort and complexity states that a team shouldn’t shoulder the responsibility of time estimates. A team can become rather adept at measuring effort and complexity accurately and quickly, and, after a few sprints team velocity can be used by the product owner or product manager to calculate time estimates based on historical performance of the team. Here again, Fibonacci sizing is helpful because there is a built-in buffer in the gaps between story point values, so when a team estimates incorrectly it will average out over time.
Finally, Fibonacci sizing provides a quick and easy delineation between user stories and epics. A user story greater than, say, 8 points becomes an epic that needs to be broken down into smaller stories. The specific number is a team preference, but once selected, it’s a great way to decide when to break up a story.