only_use_fibonacci_sequence_numbers

This shows you the differences between two versions of the page.

Both sides previous revision Previous revision | Previous revision | ||

only_use_fibonacci_sequence_numbers [2016/07/03 13:38] |
only_use_fibonacci_sequence_numbers [2020/06/04 11:12] (current) hans Removed LINKBACK |
||
---|---|---|---|

Line 1: | Line 1: | ||

+ | ====== Only Use Fibonacci Sequence Numbers ====== | ||

+ | |||

+ | A number of teams have created additional numbers to be used in estimates because they do not think that the set that are provided are enough. Remember that what we are doing is relative size estimates and so the numbers from 1 to 100 represent 2 orders of magnitude in size and so should be enough to determine how much will fit into a sprint. | ||

+ | |||

+ | The need to put additional numbers in seems to happen at both ends of the scale: | ||

+ | * At the low end because the size of, for example, typical defects work is much smaller than the size of typical new work. The approach to this problem is to simply group a number of defects together so that they make up a point. Estimating tiny amounts leads people to a false sense of accuracy in the estimates and results in additional work. | ||

+ | * At the high end because the size of something seen as much bigger than the other 100's. In this situation if the item is going to become a priority item for a release then in both situations, estimate of 100 or estimate of 1000, the very next thing you have to do before you have a real plan is to break the item down into User Stories that are less than 100 in size. | ||

+ | |||

+ | The research indicates that if you limit your discussion to a sequence of numbers, you don't spend a lot of time arguing over the exactness of the estimate. Further by having the numbers spaced out, you can get to "its a 5 or 8" pretty quickly, and then you can decide one way or the other, again reducing the amount of time wasted in doing estimates. | ||

+ | |||

+ | {{tag> | ||