Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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

Licensed under: CC-BY-SA with attribution
scroll top