Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Jun 26 '12 at 11:53

This question came from our site for professional and enthusiast programmers.

2  
Please can you clarify. It sounds like you're saying that, for some stories, you know exactly what the duration will be and therefore want to use a specific number of story points which aren't on any of your planning poker cards. Can you give some examples of stories you can estimate so accurately, as I would question whether these would really be accurate. –  Nick Jul 2 '12 at 15:52
    
There is no story whose duration estimated exactly but I wonder that Is it impossible,can't there be such situations and these estimations can't drop into intervals such [20,40],i.e. 30. –  yesildal Jul 4 '12 at 7:20
    
If your estimations are always on the upper end of the scale (or beyond!) then it sounds like you need to split up your tasks to be more granular. –  Joachim Sauer Dec 7 '12 at 6:53

4 Answers 4

up vote 4 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.