Break up the Story into tasks. Could be database development, component building, refactoring existing code,...

If the answer to every task is between 1 and 3 EngineeringDays, then the task is okay; if it is not, break the task up into small tasks. When your team feels that the story is completely tasked out, add up the tasks and that is your ManDay estimate. 

You could go further and establish who will be performing the tasks and after you have created a GanttChart like environment for you team, you will have a true StoryEstimate.

- GregJones

-----


Ask yourself the question, "What if all I had to do was implement this story? Really just this story right here. How long would that take (in weeks)?"

If the answer is more than TwoWeeks, the story is too big. Ask for the customer's help in breaking it into smaller pieces.

If you can't come up with an answer that you are confident in, you should spend a couple of hours programming on the story.

If the answer is in days instead of weeks, the story may be too small. See if there are other stories the customer is willing to combine this one with (use a paper clip).

Write the estimate in a corner of the card. Do not change the estimate, unless you really, really, really know more later than you did when you wrote it. Do not change the estimate under any circumstances because the customer doesn't like the schedule implications of a set of stories.

----

So assuming the body is a semantic template like Sheets-Johnstone hypothesizes,  that is an estimate has to be grounded in real concepts you map onto physical activities...  this is what is meant by "comprehensible" in the 3 steps below.   This is why function-pointing seems far too abstract.  It has no grounding in techknowledgy.

From Code Craft (Goodliffe) we have:

1. Break the task down into the smallest blocks possible,  effectively performing a first pass of system design.

2. When you reach a fine resolution with suitably comprehensible parts,  provide a timescale estimate for each block in man-hours or man-days.

3. once you've estimated all of the individual timescales,  place them back-to-back,  add up their durations, and voila:  an instant timescale estimate.

This strategy works because you've made a site visit and looked around a bit(you've done the mapping to your semantic template).  Never make estimates in units larger than days,  that just means you haven't touched the problem,  so your estimate cannot be reliable.  Mercilessly decompose large tasks until you end up with fine-grained--estimatable--work units.


''It's when you add up the task estimates that that everything goes up the spout. Each of your individual estimates has a probability associated with it: the probability of finishing in the estimated time or sooner. Say you have a bunch of parts a, b and c; with probabilities Pa, Pb and Pc. The probability for meeting or beating the added-up estimate, P(a+b+c), is something worse than (Pa*Pb*Pc). (See ParkinsonsLaw)''

''If you start out even money, you end up with no chance in hell. The only way to get reliable composite estimates is by starting with probability distributions and running Monte Carlo simulations of the story plan. The output distribution curve gives you the connection between possible estimates and their probabilities. Pick a point.'' --MarcThibault