What is Planning Poker?
Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.
The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.
Is there any particular reason why a Fibonacci series is used in Planning Poker? Advantage and Disadvantage
The keyword I would love to emphasize is “Estimate in relative terms ” – I will discuss about it later in Story Point
Fibonacci sequence is not the same as estimating in Story Point. It is just a unit.
You can actually estimate everything with the Fibonnaci sequence, (time ; weight ; effort ; distance ; size ; speed…)
The below is some explanation I quoted some several sites/blogs which I think they are very useful
The reason for using the Fibonacci sequence instead of simply doubling each subsequent value is because estimating a task as exactly double the effort as another task is misleadingly precise. A task which is about twice as much effort as a 5, has to be evaluated as either a bit less than double (8) or a bit more than double (13)
Several commercially available decks use the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and optionally a ? (unsure), an infinity symbol (this task cannot be completed) and a coffee cup (I need a break, and I will make the rest of the team tea).
The reason for not exactly following the Fibonacci sequence after 13 is because someone once said to Mike Cohn “You must be very certain to have estimated that task as 21 instead of 20.” Using numbers with only a single digit of precision (except for 13) indicates the uncertainty in the estimation
Another view I read in scrum.org:
https://www.scrum.org/forum/scrum-forum/7897/why-do-we-use-fibonacci-series-estimation
With Empiricism in mind, you can also use Fibonacci as a means of gauging how an estimated effort translates to work (man hours) in a Sprint
For instance:
If you run a 2-week Sprint and have noticed a trend that 5-effort is 2.5 days, 8 is close to 4 days and 13 could be a little more than half the Sprint, then it’s possible a 20-effort is a whole sprint to finish or more.
This tells us that while a lone 20 could be delivered in a Sprint, it’s way too complex, and it’s possible to break the User Story into four 5-efforts or an 8 and 13 .
User Story becomes more defined because of the break down, and you still churn out a working piece of the software.
My interpretation of the Fibonacci sequence has always been that as the uncertainty and complexity of the task at hand increase, so does the figure resulting from the sequence. The points increase significantly relative to an increase in complexity and uncertainty.
This means that when we assign a low amount of points to a task, we are more certain of the context, difficulties and attributes of that task than when we assign a high number
And finally, what is the disadvantage
A disadvantage of using Fibonacci is because of how the gap changes between numbers, any number over 1 could easily be under or overestimated.
(a) A User Story felt like it was somewhere between an 5 or 8, or (b) an 8 would either turn out to be a 13 or a 5 as the Sprint progressed. To air on the side of caution, we always used the larger number.
For reference:
