Estimates are often required in order for a project to request funding. Investors want to know what you will be building, how long it will take and most importantly how much it will cost.

Nowadays, Agile methodologies are common and out of which a regular practice is that of the Planning Poker. Planning Poker is a ceremony during which stories are estimated by each member of the (committed) team using story points. Story points are used to abstract people from a time bias and to help focus on the relative weight of a story.

Goal of estimating

Planing poker's aftermath should not solely reside in estimations. Most agile ceremonies have a duality between their obvious purpose and their hidden and usually more important benefits. Planning Poker's benefit is the discussion which sparks from gaps between estimates in the team. And even if two persons have the same estimate doesn't mean they had it for the same reason. It's exchanging among team members which leads to better comprehension and challenging of stories.

Planning Poker was never meant to precisely estimate a bunch of stories but to engage discussion around stories.

A controversial subject

Estimates are a recurring controversial subject and recently saw a discussion about this subject in French. I decided to write an article about it.

twitter_estimates
English version :

Planning Poker doesn't bring any worth to software estimates. It's but a scam to sell card decks

twitter_estimates_discussion
English version :

As with many Agile rites, Planning Poker's value isn't only in the produced artifact (estimates), but in the discussions it spurs ("I've put 2 and you 20, did you think there is this and that to be done and that we should interface with this service ?")

Drift in estimates

Estimates are used in Scrum to have a reasonable amount of stories to include in a sprint. Disparities between estimates and real amount of work needed for a story is often smoothed out in an entire sprint. I've seen people put warnings on stories which have consumed their estimates. This shouldn't be done per story but the whole sprint should be considered. It's OK to sometimes have the amount of work for a story be different from its estimate. Estimates are not facts and they can vary.

Relative Weights

Estimates in story points are given to do a comparative analysis of stories. If the relative estimates reflect the relative amount of work to actually build the story, then the teams' estimates are fine and in which case the velocity is to be changed. If the relative weights do not reflect the amount of work, then there probably needs to be a thorough analysis as to where things went wrong and how estimates could be improved.

TDLR;

Estimates are an excuse to launch a debate about what is to be done to complete a story. Collective intelligence is used to dissect a story. Story points are used to abstract away from a temporal base and evaluate stories in comparison to one another instead of nitpicking on hours. Estimates are to be taken as a whole and not on individual stories because one story can be wrongly estimated, whereas several estimated stories are less likely to be all wrongly estimated.