# Is there a reason beyond Fibonacci why Planning Poker doesn't involve a 4?

During our sprint planning meetings, we use a planning poker deck to reach a consensus on estimates, with the cards indicating how many days we estimate to need. We then use these estimates combined with our estimate for how many days we can work this sprint to determine what items we will do this sprint and which ones are for the next sprint. We do this because our developers are rather specialized and some tasks are preferably handled by certain developers. Because of this, estimating effort gives a clearer picture compared to estimating complexity. It's not pure agile, but it works for us.

During this, we find that for certain stories, 3 days is slightly too optimistic, but 5 days is too far in the other direction. In effect, we sometimes miss a card that reads 4. When this is the consensus, we do write down 4, jokingly saying that "we will be thrown out of the Agile party".

Joking aside, Is there a specific reason as to why Planning Poker doesn't have an option for 4 story points/days/whatever? I know that it originated from the Fibonacci sequence, but still, 4 is a low number, which means that as an estimate of either complexity or effort, it's still reasonably accurate.

• "Fibonacci series does help in providing arbitrary numbers which are not exact multiples and increase exponentially. So numbers like 4, 6, 10, etc. are out of the picture..."(Why is there a 20 and not 21 in some versions of Planning Poker?) – gnat May 20 '16 at 10:16
• @gnat that doesn't quite answer my question. You're saying "because they are based on the Fibonacci sequence", but even though 4 isn't part of the Fibonacci sequence, I would still argue it's a reasonable estimate to make. – Nzall May 20 '16 at 10:17
• Story points are arbitrary numbers. If you are using 1,2,3,5,8,13 and you find yourselves arguing between 3 and 4, the correct action is to start using 1,2,3,5,8,13,21 and what was '5' before is now '8', etc. Never, ever pretend a story point is a unit of time. – Steven Burnap May 20 '16 at 19:19
• 4 has been considered unlucky by developers ever since fourtran 77 – Ewan May 20 '16 at 19:50
• @StevenBurnap: "Never, ever pretend a story point is a unit of time.": But it ends up being used as a unit of time, always. At least in the four different teams I have been using it up to now. – Giorgio Mar 9 at 7:56

If you think that estimating a story as a 4 rather than a 5 adds value to the planning process, I think you misunderstand the point of the planning process. There is no value in having a highly accurate estimation for some tasks. The goal is to have consistent estimations of all tasks.

Also, if you interpreter the points as days, you're doing it wrong. While it is true that lower value points can make to one or two days, they shouldn't be treated as such.

The general concept being applied is that humans suck at estimation and that the longer the estimation, the less accurate the estimation tends to be. That is why the gaps get bigger the further out you go. It is somewhat unusual to be able to say with a high degree of certainty that some task will take exactly 33% more effort than a 3 point story.

Remember: this is an estimation task, and the units should be points, not days, and the goal in point estimation is consistency. Even if you can estimate stories with high precision some of the time, I don't think you should try. If you spend just five minutes debating whether a story is a 3, 4 or 5, you've wasted your time. You should be asking "is it bigger than a 3? If so, is it smaller than an 8?". Anything more is just wasting time. If you're trying to point out 20 stories and you have this debate on half the stories, you've needlessly extended your meeting by close to an hour.

There is no special reason why it's the Fibonacci sequence. Also, in the planning poker cards I am familiar with, there is no 21, it's a 20. So it's not even a Fibonacci sequence at all.

The primary point is that you don't have every possible number from 1 to 100 in order to avoid you spend 10 minutes discussing whether or not a story should be estimated as 26 or 27.

The whole process does not depend on every story being precisely estimated, but it does depend on that if you have enough stories estimated, some may be underestimated, some may be overestimated, but the average will in general be usable. And the current use of the Fibonacci sequence does seem to work nice for this job.

Also remember, that the story points are not supposed to be reflect a specific amount of time, but rather relative complexity. Two persons implementing the same task would not necessarily spend the same time implementing it, but they might be able to agree that story 1 is twice as complex as story 2.

For a nice introduction to agile estimation, I can recommend this presentation by Mike Cohn: Part 1 Part 2