 | Estimation |
In Sprint Planning, in order for the Dev Team to determine how many Stories can be added to the next Sprint Backlog, they must first estimate how much work each story represents.
Estimation is important, not only in determining how much work will accurately fit into one sprint (and into a product increment), but also to determine a team’s velocity – a concept that will be covered in more depth in the next sub-section.
Complexity & the Fibonacci Sequence
Estimation is no trivial process. People’s natural tendency is to measure work in units of time (“this is a 5-hour job”). It turns out, however, that time-based estimates are highly unreliable, which some have attributed to the linear nature of time. People fair better when estimating across a non-linear scale, where differences are amplified. The Fibonacci Sequence has proven well-suited for estimation in scrum, precisely because of its non-linear nature.
The goal of estimating is not to determine accurately how long a task will take, but how much work, or “complexity,” it represents in relation to previously completed tasks. People might have difficulty determining if a task were to have the value of 5, 6, or 7 on a linear scale, for example, different people on the team would have a hard time reaching a consensus. When the scale goes from 5 to 8 to 13, it’s much easier (and more accurate) for a team to reach consensus. The fibonacci sequence starts with 0, 1, 1, after which, each new number is the sum of the two previous (1+1=2, 1+2=3, 2+3=5, …). Scrum teams typically modify the beginning of the sequence as follows:
1, 2, 3, 5, 8, 13, …
While the value of each number is relative and subject and only has practical meaning at a higher level (like in a burndown), many teams try to set a 1 as a task/story that would take half a day to complete.
With a growing threshold between each number, people are more likely to agree, for example, that a given task is complex enough to be an 8 but not nearly enough to be a 13.
Importantly, if team members disagree on a complexity estimate, the difference will be more pronounced, which will encourages people to look into what factors led to the difference.
The estimation process will be described in the Sprint Planning subsection, which focuses on the sprint ceremony rather than the sprint artifact. Most importantly, it’s important to understand that estimating is an extremely important part of populating a Sprint Backlog and generating a meaningful Burndown, which by no coincidence, is the next subsection.