how to change the sequence used in planning poker

Question

Is it possible to change the used sequence in Planning Poker, for some stories, it is thought that when the stories gets larger it contains more uncertainty but stories have nearly exact time estimations and these estimations don't drop into two bounds defined by Fibonacci series.

Answer 1

Prevent Anchoring

Fibonacci Sequence is chosen because there is does not represent a linear extrapolation between the increments in the sequence, and help stop psychological anchoring on numbers based on the values on either side.

Back to the Future

The estimation isn't solely about time.

It is a composite of Time/Complexity/Risk as understood by the team. Yes it might be 30 minutes worth of effort for one team member, but 3 hours for anyone else on the team. Majority of the time it is going to be one of the 3 hour people working on the task.

Its all Relative

Stories should be rated relative to each other. The numbers in the Fibonacci Sequence discourages saying things like "Story A is twice Story B" and encourages "Story A is more like Story X" or "Story A is more than Story B but less than Story X" since the numbers get bigger and smaller very quickly on a non-linear scale.

Human Nature

Certain team members will gravitate to everything they estimate being a 3, 5 or 20 and will never budge from those numbers because they get anchored to the 3 and the 20 as upper and lower bounds in their head. The 5 is their compromise number when they are forced to do so, because everyone is usually overly optimistic. Giving realistic or pessimistic estimates; they think makes them look bad in some undefinable way. What really makes them look bad is being wrong on the low side constantly and missing commitments and deadlines constantly because of it.

Refresh Understanding

Sounds like you need to get the team to read up on how Planning Poker is really supposed to work, what the numbers actually mean in context of estimation.

Answer 2

Fibonacci is only a guideline. It is a graduated way to do rough estimates and to avoid arguing. It would be a shame to spend any significant time discussing (or arguing) if a story is actually 15 or 16 points. That is only a 6% difference. Likewise, if my team spends more than a minute or two discussing whether a story is a 3 or a 5, I will mark down 4 in the software.

Also, it is unlikely that your ability to accurately estimate spans more than an order of magnitude. If you are assigning a 1 to some stories, a 13 is really on the verge of being too large. I used to have a rule with my team that any story larger than 13 had to be broken up, but they eventually started doing that to the 13s also. We almost never have anything larger than an 8.

If your estimation meeting is long or contentious, you are getting too far into the details. Story points are fast and rough estimates, don't try to make them exact. My rule of thumb is that is should take 15 minutes per developer to estimate a two week sprint. An hour for a team of four. Don't spend more time on it than that.

Answer 3

There is at least one more reason why you do not want to change the sequence: because it'll put too much emphasis on trying to get accurate forecasts instead of rough estimates, which is what story pointing should get you.

I'm a people manager and an early mistake we made was to put a lot of emphasis on points, velocity, etc. Our engineers, realizing that points were important to management, were incentivized to maximize said points such that we quickly entered into debates over them. That energy is a complete waste to the product development process and should be reduced/eliminated.

I don't believe points are terribly useful in trying to derive schedules over the short run. After a half-dozen or more sprints with the same team(s)? Then yes, management can extrapolate assuming there is a well groomed backlog, which is itself easier said than done.

Do you want engineers arguing over points or getting stuff done? Your choice based on what you choose to emphasize.

Answer 4

No you should not change sequence for some user stories. Use the same sequence for the whole project. Fibonacci sequence is used because it describes growing uncertainty with complexity of stories.

The sequence doesn't have anything to do with time estimation! It is complexity / sizing estimation. We don't estimate time for stories. We only measure how many story points we completed in previous sprints and use that measurement for computation of our expected velocity.

If you feel that your user story is not a lower bound you should always choose the upper bound because you have already showed uncertainty with lower bound. If you feel that size estimation results in big user stories with a lot of uncertainty its time to talk with product owner (he should actually initiate this because he sees that his user stories are not specific enough from your estimations) and split those stories into smaller and better defined.